作为开发人员，您将听到许多有关“代码行”的含义的疯狂，不可思议的理论。 不要相信一个。 代码行是荒谬的指标。 在极少数情况下，她会说些什么，通常什么也不说。 使用代码行做出决策就像通过页数评估一本书的质量。

有人可能会说，应用程序中的代码行越少，阅读起来就越容易。 这只是部分正确。 这是我的可读代码指标：

• 代码必须一致
  
• 该代码应提供信息。
  
• 该代码应有据可查。
  
• 该代码应使用稳定的现代函数。
  
• 代码不必太复杂
  
• 代码不应低效（不要故意编写慢速代码）

如果减少代码行数与这些指标中的任何一个矛盾，那么这将成为问题。 实际上，它几乎总是会干扰，因此，几乎总是一个问题。 但这就是问题，如果您努力满足上述条件，那么您的代码将具有理想的行数-并且您无需计算它们 。

语言不一定是“好”或“坏”


当然，除了php（一个玩笑）。 来源

我看到人们一直在说这样的话：

• 由于性能，C优于X
  
• 简洁起见，Python比X更好
  
• 由于外星人的影响，Haskell比X更好

语言比较可以简化为一句话的想法几乎令人反感。 这些是语言，而不是神奇宝贝。

别误会，语言之间肯定存在差异。 实际上几乎没有“无用的”语言（尽管有许多已过时/已失效）。 每种语言都有其独特的折衷方案。 在这方面，它们看起来像一个工具箱。 螺丝刀可以做锤子不能做的事情，但是有人会说螺丝刀比锤子好吗？

（显然，锤子更好）

在谈论语言评估之前，我想先澄清一下。 选择一种语言很少有关系 。 当然，某些事情不能用某些语言完成。 如果您正在编写前端，则别无选择。 在某些情况下，性能很重要，而X语言根本不合适，但是这种情况很少见。 通常，语言选择通常是项目中最不重要的问题之一。

以下是主要方面，我认为应该影响语言的选择（无特定指标）：

• 可用在线资源的密度（StackOverflow密度）
  
• 发展速度
  
• 错误倾向
  
• 软件包生态系统的质量和覆盖范围（是，npm，谈论质量）
  
• 表现（更多分）
  
• 就业机会（对不起，COBOL）

您无法控制的一些重要因素。 如果您从事数据科学领域的工作，那么您确实需要使用Python，R或Scala（可能是Java）。 如果这是一个爱好项目，请使用您喜欢的内容。 我只有一个无可争辩的规则。 如果该语言的大多数可能问题尚未在StackOverflow上解决，我将拒绝使用这些语言。 不是我无法解决它们，只是不值得花时间。

读别人的代码很难

阅读别人的代码很困难。 罗伯特·马丁（Robert K. Martin）在“纯代码”中谈到了这一点：“实际上，读写代码的时间比例远大于10：1。我们在尝试编写新代码时会不断读取旧代码。 ... [因此]简化了阅读，也简化了其写作。”

很长一段时间，我以为我只是在阅读别人的代码方面很虚弱。 随着时间的流逝，我意识到几乎每个程序员每天都会遇到这个问题。 读取他人的代码就像阅读外语一样。 即使您愿意选择代码作者的编程语言，您仍然必须适应各种样式和体系结构选项。 它还假定作者编写了一致且可靠的代码，这可能是正确的，也可能不是正确的。 这真的很难。 有几件事对我很有帮助。

审查他人的代码将大大提高您的技能。 在过去的两年中，我对Github上的池请求进行了很多评论。 对于每一个新代码，我对阅读别人的代码更有信心。 出于以下原因，GitHub池请求特别有用：

• 您可以在这里随时进行审核，只需找到您想要贡献的开源项目即可。
  
• 在有限的上下文中阅读（单个功能或错误）。
  
• 它需要注意细节，这将使您欣赏每一行。

第二种技术将有助于读取他人的代码，该技术更为独特。 这是我发明的一种技术，它确实减少了我需要适应别人的代码库的时间。 看完我要阅读的代码样式之后，我首先打开vi并开始以相同的样式编写代码。 当您以新样式编写代码时，它还可以提高您的阅读能力。 当您自己经历时，样式将变得不那么陌生。 即使我只是在Github上观看了一个随机项目，我也会迅速应用这种技术。 自己尝试。

您将永远不会编写“完美”的代码

在开始团队合作之前，我已经独自编程四年了。 在大部分时间里，我只是假设行业中的每个程序员都编写了完美的代码。 我认为在编写“完美”代码之前还只是时间和精力的问题。

这是我以前很担心的事情。 当我加入团队后，很快就发现没有人在编写“完美”的代码。 但是系统中包含的代码几乎总是“完美”的。 怎么了 答：代码审查。

我与非常出色的工程师团队合作。 这些是您可以花钱买的最有能力，最有信心的程序员。 如果有人提出未经审查就提交代码，我们团队的每个成员（包括我在内）都会开始真正的恐慌攻击。 即使您认为自己是下一个比尔·盖茨，也一定会犯错误。 我什至没有在谈论逻辑错误，在谈论错别字，遗漏字符。 你的大脑根本没有注意到。 另一双眼睛是干什么的。

尝试与关注细节并乐于批评您的工作的其他人一起工作。 起初很难听到批评，但这是改善情况的唯一一致的方法。 尽最大努力在代码审查期间不要采取防御性立场，也不要亲自发表任何评论。 您不是您的代码。

在代码审查中，如果作者做出了我不熟悉的选择，如果他的选择与流行观点不同，我将立即进行谷歌搜索。 不是说民意总是对的，而是民意是默认的选择。 如果有人决定不接受流行的选择，那很好，我只是想知道这是有道理的。 在审查代码时，了解所做决策的依据非常重要。 另外，从初学者的角度看同样的问题，人们通常会注意到一个人永远不会注意的事情。

程序员的工作并不意味着每天要进行8个小时的编程

这是一个非常普遍的问题，但是人们从来没有给出明确的答案。 普通开发人员或“优秀”开发人员每天花多少钱编写代码？

每天只有四个小时以上的代码很少

那些不同意这些规则的人要么是规则的例外，要么是为过度利用它们的公司工作的。 编程是一项令人费解的精神工作。 期望某人每周五天每天8个小时编写代码是完全不合理的。 有时候，您需要按时完成任务，或者每次会话需要做更多事情，但是很少，而且很少。 当我说“很少”时，我的意思是永远不会。 避免由于计划不佳/人员短缺而使您的工作流受到滥用并加班。

对于该协议，即使公司本身也无法为您每天主动编程8个小时带来利润。 您的老板可能认为是这样，但它是短视的，并且忽略了长期后果，因为它影响生产力和心理健康。

只是为了清楚起见，我不建议您每天仅工作四个小时。 剩下的四个小时通常最好花在：

• 与工作相关且无关的研究
  
• 与同事讨论您的工作
  
• 帮助工作中遇到问题的同事
  
• 未来工作计划
  
• 代码检查
  
• 会议会议

我也强烈建议您在白天定时休息并参加运动（至少不宜长时间）。 运动对抗精神疲劳的好处已得到充分证明。 我个人发现，如果注意力不集中，运动特别有帮助。

这些是我想在大学学习的东西，而不是纯粹的理论。 在编写过程中，我考虑了很多其他细微差别，但这是另一篇文章的主题！