第17章 味道与启发
注释
不恰当的信息，如那些本该更好在源代码控制系统中保存的信息。
过时、无关或不正确的注释就是废弃的注释。
冗余的注释、注释掉的代码，都应该删除。
系统
系统应当能够用单个命令签出系统，并用单个指令构建它。
应当能够发出单个指令就可以运行全部单元测试。
函数
函数不应该有过多的参数。
不应该有输出参数，这违反直觉。
函数不应该有标识参数，这是在说函数不止做了一件事。
用不到的函数就删除它。
一般性问题
理想的源文件应该只包括一种语言。
遵循“最小惊讶”原则，函数或类应该实现其他程序员有理由期待的行为。
警惕函数的边界行为，谨慎的去测试每种边界条件。
不要忽视代码安全。
Don’t Repeat Yourself，别重复你自己。
创建抽象需要分离高层级一般性概念与较低层级细节概念。
孤立抽象是软件开发者最难做到的事之一，而且一旦做错也没有快捷的修复手段。
基类对派生类应该一无所知。
模块包含的信息不应过多。
垂直分隔：变量和函数应该在靠近被使用的位置上声明，垂直距离要短。
前后一致：最小惊讶原则。
不互相依赖的东西不该耦合。
类的方法只应对其所属类中的变量和函数感兴趣，不应依恋于其他对象类操作该对象的内部数据。
使用多个函数，通常优于向单个函数传递某些代码来选择函数行为。
代码要尽可能具有表达力，不要晦涩难懂。
合适的代码应该在合适的位置出现。
通常应该倾向于选用非静态方法。
使用解释性变量。
函数名称应该表达其行为。
真正理解函数的算法，全部通过测试还不行。
用多态代替If/Else或Switch/Case。
遵循标准约定。
用命名常量来代替魔术数。
在代码中做决定时，确认自己足够准确。
结构基于约定。
封装条件、避免否定式条件。
函数只该做一件事。
常常有必要使用时序耦合，但不应该掩蔽它。
封装函数的边界条件。
函数应该只在一个抽象层级上。
在较高层级放置可配置的数据。
不要传递浏览，即a.getB().getC().doSomething()。
Java
通过使用通配符避免多长的导入清单。
不要继承常量。
枚举 > 常量。
名称
采用描述性名称。
名称应与抽象层级相符。
尽可能使用标准命名法。
无歧义的名称。
避免编码。
测试
测试不足。
使用覆盖率工具。
别忽略小测试。
测试边界条件。
全面测试相近的缺陷。
测试失败的模式有启发性。
测试应该快速。
专业性和技艺来自于驱动规程的价值观。