整洁代码
代码永存
糟糕代码所产生的影响
糟糕代码可以毁掉一个公司
混乱的代码 》生产力下降 》增加新人 》代码更混乱 》公司破产
有意义的命名
名副其实
为什么？
选好的时间要花时间，但省下的时间比花掉的多
一旦发现更好的的名称，就替换旧的。这样做读代码的人会更开心
避免误导
以同样的方式拼写同样的概念才是信息，拼写前后不一致就是误导
误导性名称真正可怕的例子，是用小写字母 l和大写字母O作为变量名，或名称的一部分
做有意义的区分
如：copyChars(String a1,String a2)，a1 应改为 source 和 a2 改为 destination
使用读得出来的名称
如：private Date geymdhms；改为generationTimeStamp
使用可搜索的名称
如：SUCCESS_CODE 与 0
避免使用编码
匈牙利标记法
如：phoneString，phoneNumber 。这里phone类型定义本身就是String或者Number，没必要再多此一举
成员前缀
如：private String m_name
避免思维映射
不应当让读者在脑中把你的名称，翻译为它们熟知的名称
类名
名词或者名词短语
如：book。注：不建议名词复数
别扮可爱
holyHandGrenade（神圣手雷，手雷爆炸会消灭一些事物相当于删除） 与 deleteItems
每个概念对应一个词
如：获取使用get、fetch、retrieve
别用双关语
避免将同一单词用于不同意思，同一术语用于不同概念
使用解决方案领域名称
如：queue（队列）、factory（工厂模式）
使用源自所涉及问题领域的名称
如信贷领域：contract（合同）、putout（放款）、loan（借据）、paymentSchdule（还款计划）
添加有意义的语境
如：addrFirstName、addrLastName
不要添加没用的语境
如：GSDAccountAddress 给类名添加了无用的GSD前缀 （Gas Station Deluxe的缩写）
函数
短小
例子：经常会听到有人说一个函数不能大于一屏，但这是一个什么样的概念呢。这句话还是20世纪80年代流行了，当时的VT100屏幕只有20行80列，编辑器的菜单就占用了4行。也就是说不要大于16行。
代码块和缩进
if语句，else语句，while语句等，其中的代码块应当只有一行。该行大抵是一个函数调用语句。
函数越短小，功能越集中，就越便于取个好名字
只做一件事
判断是否只做了一件事的方法
函数中的每一步骤是否都在同一抽象层级上
是否能再拆出来一个函数
编写函数的目地
把一些大的概念，拆分成另一抽象层次上的一系列步骤
Switch语句
确保每个switch都埋在较低的抽象层级中，而且永远不重复
使用描述性的名称
描述函数做的事情
例：testableHtml 改为setupTeardownIncluderRender(设置拆卸包含渲染)
函数越短小，功能越集中，就越便于取个好名字
别害怕取长名称，长而具有描述性的名称，比短而令人费解的名称要好。长而具有描述性的名称，要比长的描述性注释要好
别害怕花时间取名字，应该尝试不同的名字，实测其阅读效果。
命名方式要保持一致，使用与模块名称一脉相传的名词，动词和短语给函数命名
函数参数
合适的参数
最理想的函数参数是零，其次是一，再其次是二，应当尽量避免三
读者的角度来说，参数多了导致代码难于理解
测试的角度来说，参数越多，测试用例的组合越多，工作量越大。
一元函数的普遍形式
问该参数的问题
操作该参数
事件
标识参数
说明方法不止做一件事情
改进，应该将函数一分为二
二元函数
自然的组合正常
改进利用一些机制将其转为一元函数
参数对象
如果函数看来需要2个，3个或者3个以上的参数时，说明其中的一些参数可以封装成类了
动词与关键字
把参数名称编码成函数名
如：assertEquals(expected, actual)可改成assertExpectedEqualsActual(expected, actual)
可减少记忆顺序的负担
无副作用
副作用是一种谎言。函数只承诺作一件事情，但是做了其它隐藏起来的事
如：checkPassword()方法中做了session.initialize()的调用，会导致清除会话的风险
改进：可重全名函数名为checkPasswordAndInitalizeSession()
输出参数
会被迫检查函数的签名，就得花时间，就可能中断思路
改进：应当避免使用输出参数，如果函数必须修改某种状态，就修改所属对象的状态吧
分隔指令与轮询
函数要么做什么事，要么回答什么事，两者不可兼得
金玉良言
代码质量与整洁度成正比
花时间保持代码整洁不但有关效率，还有关生存
对细节的关注当作编程艺术的基础条件
一粒老鼠屎坏了一锅粥
勒布朗法则：稍后等于永不
破窗效应：烂代码只会越来越烂
C++语言的发明者认为：整洁的代码只做好一件事情
OTI创始人，Eclipse战略教父认为：没有测试过的代码不干净
废话永远是多余的，Variable一词永远不应出现在变量名中，Table一词永远不应出现在表名中
聪明程序员与专业程序员之间的区别在于，专业程序员了解，明确是王道。专业程序员善用期能，能编写其它人能理解的代码
