代码应当易于理解
代码的写法应当使他人理解它所需的时间最小化
把信息装进名字中
清晰和精确比装可爱好
使用专业的词
使用具体的名字来更细致地描述事物
给变量名带上重要的细节
为作用域大的名字采用更长的名字
有目的地使用大小写，下划线等
要多问自己几遍：“这个名字会被别人解读成其他的含义吗？” 要仔细审视这个名字，不会被误解的名字是最好的名字
命名极限最清楚的方式是在要限制的东西前加上max_或者min_
为布尔值命名时，避免使用反义的词（例如disable_ssl）
要小心用户对特定词的期望。例如，用户会期望get()或者size()是轻量的方法
审美
一致的风格比“正确”的风格更重要
如果多个代码块做相似的事情，尝试让他们有同样的剪影
把代码按“列”对齐可以让代码更容易浏览
如果在一段代码中提到A,B,C，那么不要在另一段中说B,C,A，选择一个有意义的次序，并始终用这样的顺序
用空行来把大块代码分成逻辑上的“段落”
注释
注释的目的是尽量帮助读者了解的和作者一样多
什么地方不需要注释：
- 能从代码本身中迅速地推断的事实
- 用来粉饰烂代码的“拐杖式注释”--应该把代码改好
你应当记录下来的想法包括：
- 对于为什么代码写成这样而不是那样的内在理由（“指导性批注”）
- 代码中的缺陷，使用像TODO:或者XXX:这样的标记
- 常量背后的故事，为什么是这个值
站在读者的立场上思考：
- 预料到代码中哪些部分会让读者说：“啊？” 并且给他们加上注释
- 为普通读者意料之外的行为加上注释
- 在文件/类的级别上使用“全局观”注释来解释所有的部分是如何一起工作的
- 用注释来总结代码块，使读者不至于迷失在细节中
注释应当有很高的信息/空间率
尽量精确地描述函数的行为
在注释中用精心挑选的输入/输出例子进行说明
声明代码的高层次意图，而非明显的细节
用含义丰富的词来使注释简洁
控制流
把条件，循环以及其他对控制流的改变做的越“自然”越好，运用一种方式使读者不用停下来重读你的代码
相对于追求最小化代码行数，一个更好的度量方法是最小化人们理解它所需的时间
当你对代码做改动时，从全新的角度审视它，把它作为一个整体来看待
在写一个比较时，把改变的值写在左边并且把更稳定的值写在右边更好一些
你也可以重新排列if/else语句中的语句块，通常来讲，先处理正确的/简单的/有趣的情况
尽量不要用三目运算符
嵌套的代码块需要更加集中精力去理解，应该把它们改写成更加“线性”的代码来避免深浅套
通常来讲提早返回可以减少嵌套并让代码整洁
表达式
把你的超长表达式拆分成更容易理解的小块
要小心“智能”的小代码块--它们往往在以后会让别人读起来感到困惑
引入“解释变量”来代表较长的子表达式，这种方式有三个好处：
- 它把巨大的表达式拆成小段
- 它通过用简单的名字描述子表达式来让代码文档化
- 它帮助读者识别代码中的主要概念
用德摩根定理来操作逻辑表达式--可以把布尔表达式用更整洁的方式重写（例如if(!(a&&!b))变成if(!a||b)）
有时需要把问题“反向”或者考虑目标的对立面
变量与可读性
你希望你的同事随时都觉得是在面试吗
让你的变量对尽量少的代码行可见
操作一个变量的地方越多，越难以确定它的当前值
减少变量，即那些妨碍的变量
减小变量的作用域，越小越好，把变量移到一个有最少代码可以看到它的地方，眼不见，心不烦
只写一次的变量更好，那些只设置一次值的变量（或者const, final, 常量）使得代码更容易理解
重新组织代码
把一般代码和项目专有的代码分开
应该把代码组织得一次只做一件事情
把想法变成代码，用自然语言描述解决方案
最好的代码就是没有代码
删除没用的代码
从项目中消除不必要的功能，不要过度设计
重新考虑需求，解决版本最简单的问题，只要能完成工作就行
经常性地通读标准库的整个API，保持对他们的熟悉程度--“不要重复造轮子”
测试
测试也应当具有可读性，以便其他程序员可以舒服地改变或者增加测试
对使用者隐去不重要的细节，以便更重要的细节会更突出
让错误消息具有可读性
又简单又能完成工作的测试值更好
每个测试的最高一层应该越简明越好，最好每个测试的输入/输出可以用一行代码来描述
如果测试失败了，它所发出的错误消息应该能让你容易跟踪并修正这个bug
使用最简单的并且能够完整运用代码的测试输入
给测试函数取一个有完整描述性的名字，以使每个测试所测到的东西很明确，不要使用test1()，而要使用test_<functionName>这样的名字
最重要的是，要使它易于改动和增加新的测试
时间： 2024-11-05 22:44:12