代码 干净
罗伯特·C·马丁的经验教训
目录：
- 清洁法规 书的概述—罗伯特·C·马丁（鲍勃叔叔）
- 什么是清洁代码？
- 在软件中编写有意义名称的提示。
- 使功能易于阅读和理解的规则。
- 注释代码，您应该对错误代码进行注释还是将其重写？
- 单元测试 ，测试驱动开发（ TDD ）的好处
总览
“高级程序员将系统视为要讲的故事，而不是要编写的程序。” — Bob叔叔。
干净的代码- 《敏捷软件技巧手册》是开发人员必读的书，尤其是当您想成为更好的软件开发人员时。 本书介绍了什么是干净代码以及可以帮助您编写干净代码的最佳实践。
它可以帮助我提高编码技能，并在我的职业生涯中脱颖而出。 通过这篇文章，我想分享我的经验教训并总结本书的要点，我认为这对您非常有用。
关于作者
罗伯特C.马丁，通常称为鲍勃叔叔 ，一直是许多著名的书作为清洁编码器，清洁建筑和自1970年以来专业软件和作者更多 。
什么是清洁代码？
作者问过许多有经验的，经验丰富的程序员对Clean Code的许多定义，他们认为呢？
Bjarne Stroustrup，C ++的发明者和The C ++ Programming Language的作者：
我喜欢我的代码优雅而高效。 逻辑应该简单明了，以使错误难以隐藏，最小化依赖关系以简化维护，按照明确的策略完成错误处理，并且性能接近最佳，以免诱使人们以无原则的优化使代码混乱。 干净的代码可以很好地完成一件事。
面向对象的分析和设计及其应用的作者Grady Booch：
“干净的代码既简单又直接。 干净的代码读起来像写得很好的散文。 简洁的代码永远不会掩盖设计师的意图，而是充满清晰的抽象和直接的控制线。”
OTI创始人，Eclipse策略的教父“大”戴夫·托马斯（Dave Thomas）：
原始代码可以由原始作者以外的其他开发人员阅读和增强。 它具有单元测试和验收测试。 它具有有意义的名称。 它提供了一种方法，而不是多种方法来完成一件事情。 它具有最小的依赖关系，这些依赖关系已明确定义，并提供了清晰且最小的API。 代码应具有文化素养，因为取决于语言，并非所有必要的信息都可以单独用代码清楚地表达。
根据以上定义和我的编码经验， Clean Code的主要特征包括：
- 优雅 ：简洁的代码令人赏心悦目 ，应该使您微笑。
- 可读性 ：简洁的代码应像散文写得井井有条。
- 简单 ：用“单一责任原则”（SRP）做一件事。
- 可测试 ：运行所有测试。
在下一节中，我将分享有关如何编写“干净代码”的信息。
有意义的名字
应用程序中的所有内容都有名称，从变量，函数，参数，类，模块到包，源文件，目录。
命名是每个开发人员最常见的问题。 正如Phil Karlton所说：
“计算机科学中只有两件难事：缓存失效和命名。” — Phil Karlton
名称是将代码意图传达给阅读代码的开发人员（包括您自己）的强大方法。 选择好名字需要花费时间，但会使您的代码更好， 更简洁 。 它使您的代码易于被其他开发人员以及您以后的人阅读。
在这本书中，鲍勃叔叔分享了一些简单的规则来创建好名字：
应该：
使用意图透露名称
这意味着选择显示意图的名称，该名称应告诉您它为什么存在，它做什么以及如何使用。 如果名称需要注释，则该名称不会显示其意图。 它使您的代码更易于理解和以后进行更改。
# bad
t = Date.today # the name t reveals nothing.
# good
today = Date.today
使用可发音的名称
人类擅长单词，而且从定义上讲单词是可以发音的。
如果您无法发音，那么您就不能在听起来像个白痴的情况下讨论它。 这很重要，因为编程是一种社交活动。
# bad
ymdhms = Time.current # date, year, month, day, hour, minute, second
# good
today_timestamp = Time.current
类名
类和对象应具有名词或名词短语名称，例如Customer，WikiPage，Account和AddressParser。 避免在类名中使用诸如Manager，Processor，Data或Info之类的词。
类名不能是动词。
方法名称
方法应具有动词或动词短语名称。 示例： createUser ， deletePhoto或save
每个概念选一个词
应用程序中的一个和相同的概念应具有相同的名称。 例如，将fetch ， retrieve和get作为不同类的等效方法是令人困惑的。
每个概念使用相同的词将有助于开发人员更容易理解代码。
不应该：
编码方式
编码的名称很少发音，很容易输错。
心理映射
读者不必在头脑上将您的名字翻译成他们已经知道的其他名字。 此问题通常是由于选择不使用问题域术语或解决方案域术语而引起的。
聪明的程序员和专业的程序员之间的一个区别是专业人士明白清晰为准 。 专业人士善用自己的力量，编写他人可以理解的代码。
双关语
避免将同一单词用于两个目的。 对两个不同的想法使用相同的术语本质上是一个双关语。
功能
您如何使功能传达其意图？ 有一些最佳实践可帮助您编写易于阅读和更改的良好功能。
小
功能的第一个规则是它们应该很小。 功能的第二个规则是它们应该小于该值。
做一件事
函数应该做一件事。 他们应该做好。 他们只能这样做。
遵循单一责任原则 （SRP）
功能参数
函数应具有<3个参数。
函数的理想参数个数为零（尼拉度）。 接下来是一个（单声道），紧接着是两个（双声道）。 在可能的情况下，应避免使用三个参数（三重性）。 超过三个（多义词）需要非常特殊的理由-因此无论如何都不应使用。
不要重复自己（干）
复制是软件中的问题。 已经创建了许多原则和最佳实践来减少重复代码。
使用描述性名称
与上一节中说明的规则有意义的名称相同。
“高级程序员将系统视为要讲的故事，而不是要编写的程序。” — Bob叔叔。
如果您很好地应用了上述规则，则您的功能将易于阅读，易于理解，组织合理并能够讲述系统的故事。
注释
“不要评论错误的代码-重写它。”
— Brian W. Kernighan和PJ Plaugher
注释不能弥补错误的代码。
用注释代码说不！
单元测试
测试代码与生产代码一样重要。
测试驱动开发 （TDD）：是一种软件开发过程 ，它依赖于非常短的开发周期的重复：将需求转换为非常具体的测试用例，然后对该软件进行改进以仅通过新的测试。
Bob叔叔用以下3条法律描述了TDD：
- 第一定律：在编写失败的单元测试之前，您不得编写生产代码。
- 第二定律：您编写的单元测试可能不会超过失败的数量，并且编译不会失败。
- 第三定律：您编写的生产代码数量可能不足以通过当前失败的测试。
测试对于应用程序来说就像生产代码一样重要，因为测试可以使您的代码干净，灵活和可维护。 如果您进行了测试，则不必担心更改代码并减少错误。
单元测试可帮助我更深入地睡眠！
结论
在本文中，我与您分享了从Robert C. Martin（鲍勃叔叔）那里获得的有关“清洁代码”的有用经验。 对于每个想要在职业生涯中脱颖而出的开发人员来说，这都是至关重要的。
参考文献：
- 清洁代码手册： 清洁代码手册，软件和Craft.io
- 清洁代码博客： https ： //blog.cleancoder.com/
- TDD的周期： https ： //blog.cleancoder.com/TheCyclesOfTDD.html
- SRP： https ： //en.wikipedia.org/wiki/Single_responsibility_principle
翻译自: https://hackernoon.com/how-to-write-clean-code-d557d998bb08
代码 干净
9078
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
