推荐一篇阿里巴巴高级开发工程师朱剑分享的关于代码整洁的文章。希望对你有帮助。
任何傻瓜都能写出计算机能理解的代码。优秀的程序员编写人类能够理解的代码。普通工程师堆代码，优秀工程师优雅代码，优秀工程师简化代码。如何写出优雅、干净、易懂的代码，是一门学问，也是软件工程实践中的重要环节。我推荐三本经典的书，《代码清洁之道》、《写可读代码的艺术》和《重构:改进现有代码的设计》。下面将着重从注释、命名、方法、异常、单元测试等方面总结一些代码整洁的最佳实践。，大部分是以上三本书的精华，也有一部分是我工程实践的总结。由于篇幅有限，本文将在总结中给出一些实用的建议，后续还会有文章给出一些代码整洁的例子。
给…作注解
不要评论不好的名字。一个好的名字比一个好的评论更重要。不要“拐杖评论”。好代码>:坏代码+好注释在文件/类级别使用全局注释来解释所有部分是如何工作的。一定要注释常量。团队统一定义并标记TODO的未决问题。FIXME知道有问题的代码HACK必须采用粗略的解决方案。
在评论中使用精心挑选的输入和输出例子来解释。注释应该陈述代码的高层意图，而不是明显的细节。不要添加关于代码工作的信息。不要给代码源代码中的html注释git能做什么。增加阅读难度是件很麻烦的事。注释必须描述最近的代码注释。公共api需要添加注释。其他代码应该小心使用注释。典型的差评，不合适的信息，废弃的评论，多余的评论，差评。带注释的代码。
唯一真正好的注释是你尽量不写的注释不应该有常规注释，比如setter/getter注释。不要添加日志注释，比如修改时间等信息(git能做的)。注释必须表达代码之外的东西，以及代码可以包含的内容。如有必要，请评论意图(为什么)而非实现(如何)。大家会看到代码是合适的。
名字
尽量使用标准的命名方式，如设计模式、常见的学术名词等。要找到更有表现力的词，使用更专业的词，比如fetch或download而不是get，避免空通用名。比如tmp用具体的名字来详细描述事物，给变量名带来重要的细节，比如加单位ms对作用域大的名字用较长的名字，作用域小的变量用较短的名字来表示布尔值加is，h as，。
变量的长度应该与其作用域相对应。不要怕名字长。长的描述性名称比短的和易混淆的名称更好。函数名应该解释副作用。名字应该表达关于函数、变量或类的所有信息。请不要掩盖副作用，比如CreateAndReturnXXX方法
函数不要长到100行，最好封顶20行if else while等控制语句，其中代码块应该只有一行，也就是一个函数调用语句的锁定级别不要超过两层。一个函数只做一件事，一个函数应该不能抽象另一个函数。
公共函数调用的私有函数后面是零个参数，最长的不要超过三个参数。尽量不要输出参数。如果一个函数传入三个或更多的参数，最好将它们抽象为类标识参数。把一个布尔值传递给一个函数来区分不同的业务是很难看的。应该拆分成多个功能。
不要返回空值、抛出异常或返回特殊对象，尽量避免NPE引入空值异常和错误。
提取try catch中包含的代码块，其中代码块抽象为函数抛出的每个异常，并提供足够的环境描述，从而确定错误的来源和位置。不要把系统错误归咎于偶然的事件并发。
将与并发相关的代码与其他代码分开，严格限制对可能共享的数据的访问，避免使用一个共享对象的多个同步方法，保持同步区域较小，尽可能少地设计临界区单元测试。
不要害怕单元测试的方法名太长或者太麻烦。测试函数的名字就像注释一样。不要追求太高的测试覆盖率。测试代码的前90%通常比后10%花费的时间少。用能够完全使用代码的最简单的测试输入，给测试函数一个完整的描述性名称。例如，Test _ test代码和生产代码一样重要。如果测试代码不能保持干净，你很快就会在每次测试中丢失一个断言，单次测试中的断言数量要尽量减少，也就是一个断言。快速快速独立测试应该是相互独立的，可重复测试应该在任何环境下重复进行。自验证测试应该及时输出布尔值。最好的方法是TDD。
代码结构
代码长度应控制在100-120个字符。用一个最多200行、最长500行的文件来构建一个优秀的系统是可能的。密切相关的代码应该彼此接近。变量声明应该靠近它的使用位置。如果一个函数调用另一个函数，那么应该把它们放在一起，把调用方放在被调用方上面，从上到下显示函数调用依赖的顺序。
解释条件意图的函数要提取出来，条件要尽可能正面的表达。不要继承常量，比如在接口中定义常量，不要用继承来欺骗编程语言的作用范围。规则模块不应该知道它操作的对象的内部情况。DTO(数据传输对象)是一种只有公共变量而没有函数的类对象公开行为。不要使用诸如if(null == obj)这样的“Yoda符号”来隐藏数据。现代编译器会对if(obj = null)这样的代码给出警告。一般使用if else，而简单语句使用三元运算符。一般来说，提前返回可以减少嵌套，使代码设计得整洁。
课程应该足够短。类别应符合单一责任原则(SRP)。类和模块应该只有一个修改原因。类应该只有几个实体变量。类应该遵循依赖倒置(DIP)的原则。类应该依赖抽象，而不是具体的细节。类中的方法越少，函数已知的变量越好，类拥有的实体变量越好。
通过减少变量的数量并尽可能使它们“轻量级”来使代码更具可读性。减少变量，缩小变量范围。只写一次的变量比较好，比如常量。
最好的代码是没有代码从项目中删除不必要的功能。不要过度设计，重新考虑需求，解决最简单的版本问题。只要能完成工作，定期通读标准库的整个API，并保持熟悉就可以了。
简单地设计和运行所有的测试而不重复表达了程序员的意图，即尽量减少类和方法的数量。以上规则按重要程度排列。
无论是设计一个系统还是一个独立的模块，不要忘记使用最简单的方案。干净的代码只提供一种方法来做一件事，而不是多种方法，它的依赖性尽可能小。定义和提供尽可能少的API，减少重复代码，提高表达能力，提前构建，做简单抽象的总结。
作为保持代码整洁的一系列方法中的第一个，本文简单地从注释、命名、方法、单元测试、并发性等角度给出了一些最佳实践。下面，我们将举办一个展览，从各个方面介绍更多的实际例子。我相信每个优秀的工程师都有一颗追求优秀代码的心。你对代码整洁工程实践有什么好的建议？几百人开发的代码如何保证代码的整洁和一致性？欢迎讨论。
