代码整洁之道cleancodepdf_代码整洁之道（⼀）最佳实践⼩
结
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
普通的⼯程师堆砌代码，优秀的⼯程师优雅代码，卓越的⼯程师简化代码。如何写出优雅整洁易懂的代码是⼀门学问，也是软件⼯程实践⾥重要的⼀环。前段时间通读了三本经典书籍《代码整洁之道 》、《编写可读代码的艺术》、《重构：改善既有代码的设计》，本⽂将重点从注释、命名、⽅法、异常、单元测试等⽅⾯总结了⼀些代码整洁最佳实践，⼤部分是笔者总结于以上三本书中的精华，也有部分是笔者⼯程实践的总结。篇幅有限，本⽂将总结性给出⼀些实践建议，后续会有系列⽂章配合实践代码展开来讲述。
注释
在⽂件/类级别使⽤全局注释来解释所有部分如何⼯作
注释应该声明代码的⾼层次意图，⽽⾮明显的细节
公共api需要添加注释，其它代码谨慎使⽤注释
在注释中⽤精⼼挑选的输⼊输出例⼦进⾏说明
注释⼀定要描述离它最近的代码
注释⼀定要与代码对应
⼀定要给常量加注释
如果可能请尽量使⽤英⽂注释
团队统⼀定义标记TODO 待处理的问题FIXME 已知有问题的代码HACK 不得不采⽤的粗糙的解决⽅案
典型的烂注释不恰当的信息废弃的注释冗余注释糟糕的注释注释掉的代码
唯⼀真正好的注释是你想办法不去写的注释不要有循规式注释，⽐如setter/getter注释不要添加⽇志式注释，⽐如修改时间等信息(git 可以做的事情)注释⼀定是表达代码之外的东西，代码可以包含的内容，注释中⼀定不要出现如果有必要注释，请注释意图(why)，⽽不要去注释实现(how)，⼤家都会看代码适当添加警⽰注释
不要给不好的名字加注释，⼀个好的名字⽐好的注释更重要
不要“拐杖注释”，好代码 > 坏代码 + 好注释
不要注释中增加html标签，徒增阅读难度
不要在代码中加⼊代码的著作信息，git可以⼲的事情不要交给代码
命名
尽可能使⽤标准命名⽅法，⽐如设计模式，通⽤学术名词等
命名要更有表现⼒的词使⽤更专业的词，⽐如不⽤get⽽使⽤fetch或者download避免空泛的名字，像tmp使⽤具体的名字来细致的描述事物给变量名带上重要的细节，⽐如加上单位ms等为作⽤域⼤的名字采⽤更长的名字，作⽤域⼩的使⽤短名字变量类型为布尔值表达加上is，has，can，should这样的词会更明确
变量名称长短应该与其作⽤域对应
别害怕长名称，长⽽具有描述性的名称⽐短⽽令⼈费解的名称好
函数名称应该说明副作⽤，名称应该表达函数，变量或类的⼀切信息，请不要掩盖副作⽤，⽐如CreateAndReturnXXX
⽅法
函数不应该有100⾏那么长，20⾏封顶最好if else while等控制语句其中代码块应该只有⼀⾏，也就是⼀个函数调⽤语句函数的锁进层次不应该多于两层⼀个函数只做⼀件事，⼀个函数不应该能抽象出另外⼀个函数
某个公共函数调⽤的私有函数紧随其后
最理想的参数是零参数，最长不要超过三个⼊参，尽量不要输出参数如果函数传⼊三个及以上参数最好将其抽象为类标识参数⼗分丑陋，向函数传⼊布尔值⽤于区分不同业务的做法很丑陋，应该拆分为多个函数别传⼊null值
别返回null值，抛出异常或者返回特殊对象，尽量避免NPE
异常与错误
fetch最佳用法
抽离try catch包含的代码块，其中代码块抽象为⼀个函数
抛出的每个异常，都应当提供⾜够的环境说明，已便判断错误的来源与处所
不要将系统错误归咎于偶然事件
并发
分离并发相关代码与其它代码
严格限制对可能被共享的数据的访问
避免使⽤⼀个共享对象的多个同步⽅法
保持同步区域微⼩，尽可能少设计临界区
单元测试
使⽤最简单的并且能够完整运⽤代码的测试输⼊
给测试函数取⼀个完整性的描述性名字，⽐如 Test _
测试代码与⽣产代码⼀样重要
保证测试代码整洁，⼀旦其整洁性被破坏，其价值会很快流失，没有⼈愿意维护杂乱的代码，何况是测试代码
每个测试⼀个断⾔，单个测试中断⾔数量应该最⼩化也就是⼀个断⾔
FIRST原则快速 Fast独⽴ Independent 测试应该相互独⽴可重复 Repeatable 测试应当在任何环境中重复通过⾃⾜验证 Self-Validating 测试应该有布尔值输出及时Timely最好的⽅式是TDD
不要执着于追求太⾼的测试覆盖率，事实上测试代码前⾯90%通常⽐后⾯10%花的时间少
不要怕单元测试的⽅法名字太长或者繁琐，测试函数的名称就像注释
代码结构
代码⾏长度控制在100-120个字符
可能⽤⼤多数为200⾏，最长500⾏的单个⽂件构造出⾊的系统
关系密切的代码应该相互靠近变量声明应该靠近其使⽤位置若某个函数调⽤了另外⼀个，应该把他们放在⼀起，⽽且调⽤者应该放在被调⽤者上⾯⾃上向下展⽰函数调⽤依赖顺序
应该把解释条件意图的函数抽离出来，尽可能将条件表达为肯定形式
不要继承常量，⽐如接⼝中定义常量，不要使⽤继承欺骗编程语⾔的作⽤范围规则
模块不应了解它所操作对象的内部情况
DTO(Data Transfer Objects)是⼀个只有公共变量没有函数的类
对象暴露⾏为，隐藏数据
不要使⽤“尤达表⽰法” 如 if(null == obj)，现代编译器对if(obj = null)这样的代码会给出警告
⼀般情况使⽤if else，简单语句使⽤三⽬运算符
通常来讲提早返回可以减少嵌套并让代码整洁
设计
类应该⾜够短⼩类应该满⾜单⼀权责原则(SRP)，类和模块只有⼀个修改理由类应该只有少量的实体变量类应该遵循依赖倒置原则DIP(Dependency Inversion Principle)，类应该依赖于抽象⽽不是依赖于具体细节类中的⽅法越少越好，函数知道的变量越少越好，类拥有的实体变量越少越好
通过减少变量的数量和让他们尽量“轻量级”来让代码更有可读性减少变量缩⼩变量的作⽤域只写⼀次的变量更好，如常量
最好读的代码就是没有代码从项⽬中消除不必要的功能，不要过度设计从新考虑需求，解决版本最简单的问题，只要能完成⼯作就⾏经常性地通读标准库的整个API，保持对他们的熟悉程度
简单设计运⾏所有测试不可重复表达了程序员的意图尽可能减少类和⽅法的数量以上规则按重要程度排列
⽆论是设计系统或者单独模块，别忘了使⽤⼤概可⼯作的最简单⽅案
整洁的代码只提供⼀种⽽⾮多种做⼀件事的途径，他只有尽量少的依赖。明确定义并提供尽量少的API
减少重复代码，提⾼表达⼒，提早构建，简单抽象
⼩结
作为代码整洁之道系列的第⼀篇，本⽂从注释、命名、⽅法，单元测试，并发等视⾓简单给出了⼀些最佳实践，后续会从各个⽅⾯展开来介绍更多的实践实例，让我们⼀起左⼿代码，右⼿诗。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。