让我们面对现实，每个开发人员都希望个人的技术能力以及团队协同能力可以随着时间的推移不断得到提高。但大多数开发者都会提出的一个重要且关键性的问题：如何才能做到这一点呢？接下来，本文作者以自身的开发经验分享在编程时作为开发者应该牢记的 142 条忠告，以成为更好的程序员。

代码外观

1、关于代码布局的讨论越多，越有可能陷入没有结果的争辩中。众所周知的争论有 TAB 键与空格缩进的争论，以及大括号要不要另起一行的争论等。

2、良好的代码格式不一定是你觉得最漂亮的那个。良好的格式是更易于浏览和阅读的代码格式。

3、良好的代码外观揭示了代码的意图。这不是一项艺术工作。

4、我们需要通过良好的外观避免出现代码错误。不是为了表现我们可以创造漂亮的 ASCII 艺术。

5、虽然我们写的代码是通过计算机执行的，但却要给人类阅读。

6、如果有人想写清晰的风格，那么首先让他弄清楚自己的想法。

7、选择一种布局样式，然后坚持使用这种样式，或采用编码标准或样式指南。

8、如果你正在处理的文件不符合项目其余部分的布局约定，那么请遵循该文件中的布局约定。

命名

9、良好的命名具有描述性、正确性和惯用性。

10、如果你非常了解命名对象，那么你可以为它起一个好名字。在为变量提供神秘的名称之前，请确保你明白它是什么。

11、避免冗余。冗余表明你没有充分考虑正在创建的东西的名字。无论是类，函数还是变量。

class ItemList {
public int numberOfItems () {…}
}
// numberOfItems is unnecessarily long, repeating the word Item
5// it could be renamed to size or even length

12、采用你使用的语言中最常用的大写惯例。比如在C＃方法中，大写的Console.WriteLine（“Hello World”）

13、确保明明准确无拼写错误。

14、切勿同时修改外观和行为。用不同的版本管理它们的更改。

15、随着获得的经验调整代码外观风格。新手并不能总是保持良好的代码外观，你更应该关注程序的功能。

减少代码量

16、写的代码多不一定就意味着你写了很多软件。这可能只是意味着你写了很多Bug。

17、代码越多，意味着需要阅读和理解的越多，这会让程序更加难以理解。

18、代码量越大，隐藏Bug的地方就越多，追踪Bug就会越难。

避免非必要的代码

19、常见的没有意义的代码包括使用非必要性的条件语句和重复的逻辑构造。混乱的逻辑代表着混乱的思路。

// example
if (expresion) {
  return true;
} else {
  return false;
}
// which can be refactored to
return expresion;

20、代码保持明确简洁。避免不必要的冗长语句。它们不会为代码带来任何价值。

复制

21、不要复制代码段。将它们重构成通用的函数。通过参数表示差异性。

22、如果发现重复代码，请将其删除。

无效代码

23、无效代码是指永远不会运行，或永远无法访问的代码。

24、要么给代码运行的机会，要么干脆删掉。

无效代码的其他表现形式包括：

25、永远不会给调用的函数；

26、定义的变量永远没有不会被使用；

27、传递给内部方法的参数永远不会被使用；

28、从未使用过的枚举、结构、类或接口。

注释

29、良好的代码不需要大量注释的支持，也不需要解释它的工作原理。

30、确保每个注释都有添加的价值。代码本身就是工作原理以及方法的最好的说明。注释应该解释为什么——只有代码本身不够清楚的时候。

31、删除代码时不要将其注释掉。这会让读者感到困惑，而且很碍事。

32、每天都让你的代码变得更好。如果找到冗余和重复时，请将它们删除。

通过删除代码来改进系统

33、添加新代码可以改进系统。你也可以通过删除代码来改进系统。

无效代码会在开发过程中积累

34、应用程序的用户界面的功能已被删除，但是后台的支持代码依然保留了下来。

35、通过向导生成的用户界面代码经常会插入一些永远不会被使用的逻辑。

36、随时随地删除无效代码。这些代码很碍事，会影响你的工作速度。

37、删掉将来可能需要的代码也是安全的。届时你可以从版本控制中恢复。

38、清理代码始终应该和功能改变分开提交。

39、即使最好的代码库也有无效代码 。

警惕过去

在写代码的时候，你觉得它是完美的，但是通过认真审视旧代码，你可以发现所有代码中的陷阱。

40、回顾旧代码可以帮助你提高编程技术。

如何处置现有的代码库

接管现有的大型代码库是一件很困难的事。你必须迅速开始：

41、了解从哪里开始查看代码

42、弄清楚代码每个部分的作用以及实现方法

43、衡量代码的质量

44、了解如何操控系统

45、了解代码的惯用语，这样你的修改就可以完全融入

46、找到所有功能的可能位置（以及由此引起的后续bug）

47、了解代码的最佳方式是由知情人士为你讲解。大胆地寻求帮助！

48、学习代码的最佳方法是修改代码。然后从你的错误中吸取教训。

49、许多程序员不是努力阅读和理解现有代码，而是更喜欢说“代码很糟糕”并重写。

50、准备好遭遇很差的代码。准备好得力的工具来处理这些代码。

51、一些惨不忍睹的代码可能只是一个能力较弱的程序员编写的。或者是一个有能力的程序员在心情糟糕的时候写的。

52、遇到很糟糕的代码时，控制好自己的厌恶情绪。你需要寻找实际的方法改进这些代码。

53、不要指望任何代码（甚至是你自己的代码）完美。

54、遵循童子军规则。无论何时遇到代码，确保你离开时的代码更好。

55、缓慢而谨慎地修改代码。一次只改动一个地方。

错误处理

56、不要忽视代码中可能出现的错误。不要一再推脱错误处理（逃避不是办法）。

57、规规矩矩使用异常。了解语言的惯例和需求，有效地使用异常。

58、程序员必须了解程序错误。用户必须了解使用错误。

59、记录错误还不够好，必须要让勤奋的操作员每天注意到错误并处理好错误。

做好异常准备

60、每一步都要考虑所有可能发生的不寻常，无论你认为它们出现的几率有多低。

61、时时刻刻都要考虑从错误中恢复，并编写合适的恢复代码。

62、确保你的错误处理是惯用手法，并使用适当的语言机制。

63、在写代码的时候，严密考虑代码的运行分支。不要推迟处理“不寻常”的情况：转头你就忘了，导致代码到处是 Bug。

追踪 Bug

64、程序员写代码。但程序员不是完美的，所以程序员的代码也不是完美的。因此代码第一次不能正常工作也很正常。所以我们有 Bug。

65、我们应该采用合理的工程技术，量减少令人不快的意外事故。

66、首先调试的难度是写代码的两倍。因此，如果你尽可能巧妙地编写代码，那么显然这对于调试是不明智的。

67、将重现 Bug 的步骤降到最少。

68、确保你只专注于一个问题。

69、断言和日志（即便是简陋的 console.log 和 nodejs 断言）是有效的调试工具。可以经常利用。

70、二进制删除空格的问题可以更快地获得结果。

71、在开发软件时，花点时间写一套单元测试。

72、未经测试的代码是 Bug 的温床。而测试是杀虫剂。

73、了解如何使用调试器。然后在正确的时间内使用。

74、尽快修复 Bug。不要让它们累积成灾。

75、调试并不容易。这是我们的错。我们写了 Bug。

别忘了测试代码

单元测试是专门针对最小“单元”的功能展开的测试，以确保它们可以独立正常运行。这里的独立意味着单元测试不涉及任何外部访问：不运行任何数据库、网络或文件系统操作。

76、质量是免费的，但只有那些愿意为此付出高昂代价的人才能享有。

77、为了改进软件开发，我们需要快速反馈，以便在出现问题时立即掌握问题。良好的测试策略可以提供快速的反馈回路。

78、在编写代码时编写测试。不要推迟测试，否则测试就不会那么有效了。

79、所有测试都应作为持续集成工具链的一部分在构建服务器上运行。

80、测试应用程序中的重要内容。

81、全局变量和单例对象是可靠测试的噩梦。你无法轻易测试拥有隐藏依赖项的单元。

82、重构代码，提高可测试性，以便获得更好的代码设计。

83、程序测试可以展示 Bug 的存在，但永远无法证明没有 Bug。

如何处理复杂性

84、简单性是伟大的品质，但需要付诸福利才能实现，人人都应该重视简单性。但糟糕的是：大家更喜欢复杂性。

85、复杂性通常是偶然的，很少有人会故意添加。

86、推迟设计决策，直到你必须做决定的时候。在还不了解需求时，不要做出架构决策。不要猜。

完美的实践

87、程序员需要良好的品味和美感才能编写出色的代码。

88、任何聪明的傻瓜都会让代码变得更大、更复杂和滥用。我们需要一点天才的力量以及很大的勇气，才能朝着正确的方向前进。

89、良好的软件开发不是牛仔式编程，扔掉第一个你能想到的代码。这是一项需要深思熟虑和朝着正确方向努力的工作。

90、优秀的程序员在工作中很谦虚。他们敢于承认他们并不知道所有的一切。

91、良好的代码和良好的程序员源于以正确的方式编写正确的东西的愿望。

团队合作

92、程序员团队有一套规则。这些规则定义了我们的工作以及我们的工作方式。同时也描述了编程文化。

93、不要依赖模糊的不成文的团队“规则”。要明确隐含的规则，并控制你的编程文化。

94、要从根本原因上修复 Bug，而不是表面症状出现的位置。坚持修复表面症状不会简化代码。

95、避免在代码中隐含假设。

96、只需编写所需的代码。任何额外的复杂性都将成为负担。

97、停下来想一想。不要写愚蠢的代码。

98、承认你的错误和错误的编程决定。并从中吸取经验教训。

99、勇敢地使用你的大脑。你有权批评代码并做出改进代码的决定。

100、了解使软件易于修改的原因，并努力建立具有这些属性的软件。

101、修改代码需要的是勇气和技巧。而不是鲁莽。

102、通常最好进行一系列频繁、少量、可验证的改动，而不是一次大规模的代码变动。

103、避免复制和粘贴编码。重构逻辑建立共享函数和公共库，避免重复代码（和重复的 Bug）。

104、编写小的模块化代码段。保持干净整洁。

105、代码应该“共享”，因为它可以用于多个客户端，而不是因为开发人员想要创建一个漂亮的共享库。

106、不要拒绝别人的代码。使用现有的库可能更好，避免编写自己的版本。

107、建立软件版本需要规范和规划。这不仅仅是在开发人员的 IDE 中点击“构建”。

108、始终从头开始构建新的软件。切勿重复使用构建软件的旧代码。

109、简化构建过程，只需一步即可自动完成流程的所有部分。使用脚本语言执行该操作。

110、在 CI 服务器上部署构建以确保其健康。从同一系统发布正式版本。

111、不断学习。积极学习新知识。

112、我们的学习往往过于狭隘。考虑更广泛的参考范围。从许多领域中汲取灵感。

113、学习时记笔记。即使过后你会扔掉它们。

114、如果不能用简单的方式做出解释，那么意味着你理解的不够透彻。

115、教别人学习一个主题，可以促进自己更好地学习该主题。

116、耳听为虚，眼见为实。实践出真知。

117、使用你刚学到的东西可以加强记忆。尝试示例，回答问题，创建业余项目。

118、警惕停滞不前。渴望成为更好的程序员，就必须挣脱最舒适的生活方式。

119、投入时间和精力来提高你的技术力。这项投资物有所值，你会收获丰厚的回报。

120、不要试图通过编写不可读或不必要的“聪明”代码来证明自己“不可或缺”。

121、获取软件资格证是一种荣誉。

122、不要一叶障目。要准备好面对新挑战，学习成长为更好的开发人员。

123、爱所有的编程语言。

124、学习遵循不同语言的惯例和范例。

125、考虑学习一些不再常用的语言，以了解编程历史。

126、一个优秀的程序员知道多种语言和多种惯例，这可以拓宽他们的解决方案。改进他们编写的代码。

127、使用编程语言是你每天的例行工作。

128、要用语言编写最好的代码，你应该接受它的风格和惯例，而不是强迫你自己。

129、优秀的程序员是良好的沟通者。他们会听说读写以及编程。

130、不要指望一夜之间成为语言大师，在工作中不要感到沮丧。

131、首先集中精力处理最重要的事情。什么是最紧迫的，什么会产生最大的价值？

132、让计算机帮忙处理重复性的工作。使用脚本完成自动化。

133、将大型任务分解为一系列小任务，这样易于理解的任务。并且可以使你更准确地判断这些进展。

134、确认你定义的“已完成”是什么。

135、如果你不知道什么时候能够完成，那请不要着急动手。

136、使用代码中编写的测试来定义代码的完成和工作的时间。

137、不要做非必要的工作。只做必须完成的工作。然后住手。

138、遇到问题，在开始解决问题前，请确保你考虑过多种解决方案。

139、目标明确是优秀程序员的品质。

140、注释并不一定能改善代码。简单明了的代码不需要额外的注释支持。

142、了解开发的方法、趋势、宣言和流行。

 

原文：https://hackernoon.com/139-traits-that-make-a-better-programmer-4d0d916b9f78

作者：Sadick，软件工程师，热衷于构建事物。

译者：弯月，责编：屠敏