有意义的命名
避免误导
错误缩写简称，例如：hp<br>
别用“字母l”和“字母O”
accountList表示一组账号，应该使用accountGroup合理一些
提防使用细小区别的名称，例如：XyzController和XzzController
做有意义的区分
变量名称，例如错误数字命名：a1、a2、a3<br>
冗余的废话，例如：info、data等
使用读的出来的名称<br>
使用错误的缩写，例如：generationTimeStamp-->genymdhms<br>
使用可以搜索的名称
变量作用域大，应该取便于全文搜索的名称<br>
避免使用编码<br>
使用前缀，例如：m_desc
接口与实现，例如：使用I开头接口名称IShapeFactory
避免思维映射<br>
避免取得名称，翻译成他们熟知的名称<br>
方法名
应采用动词或者动词短语，例如：get、set、is前缀，deletePage、save等<br>
每一个概念对应一个词<br>
查询：query、select使用一种风格
controller控制层，不要采用manager或者driver这类不统一风格
别用双关语<br>
例如：add添加还是追加，使用insert或者append更加精准表示<br>
使用解决方案领域名称<br>
例如：AccountVisitor账户访问者、JobQueue工作队列<br>
使用源自所涉及问题领域名称<br>
添加有意义的语境
例如：名字 lastName，fristName
不要添加没用语境<br>
例如：GSDaccountAddress,不必要的前缀<br>
函数<br>
只做一件事
每个函数方法只做一件事情（单一原则）<br>
每个函数的抽象层级
一件事情抽象层一个方法，遵循自顶向下原则：自下原则<br>
switch语句<br>
应该把这个逻辑抽象到更底层代码中
函数参数
标识参数
应禁止传入布尔值作为参数，如果有必要可以拆分成两个方法
二元函数
尽量写成一元函数，如果有必要，必须命名清楚名称
三元函数
少些，有足够的理由可以写三元函数<br>
无副作用
函数中不能包含隐患作用，输出参数需要修改，尽量使用对象的状态<br>
分割指令与询问<br>
判断值和修改值，必须得分开处理事情，例如：attributeExist("user")和setAttribute("a",userName)
使用异常代替返回错误码
抽离try/catch代码
主体代码块中抽离出来<br>
错误处理就是一件事<br>
try/catch/finally后面应该无其他内容
依赖磁铁
例如：消除错误码枚举类，应该使用异常派生类
对象和数据结构
数据抽象
数据内部细节，应该隐藏细节，统一接口暴露出去
数据、对象的反对称性
过程式的代码难以添加数据结构，必须修改所有函数<br>
面向对象的代码，难于添加新函数，必须修改所有类<br>
数据传输对象DTO
公共变量数据结构，没有函数的类，应用与数据库、通信场景<br>
错误处理
使用异常而非返回码
例如：消除错误码枚举类，应该使用异常派生类
先写Try/Catch/Finally语句<br>
使用不可控异常
例如：可控异常（checked exception），破坏每个调用层链，底层修改，上层也要跟着修改，破坏封装性
出现异常要详细堆栈信息<br>
要打印出错误，堆栈轨迹信息<br>
定义常规流程<br>
特列对象：创建一个类、或者配置一个对象，封装到对象中<br>
别返回null值<br>
避免别人出现NPE异常，例如：返回异常或者空对象列表<br>
边界
使用第三方代码
浏览与学习边界<br>
整洁边界
如何保证尽量小，改动原有的类，例如：适配器模式Adapter<br>
使用尚不存在的代码
单元测试
TDD三定律
在编写不能通过单元测试前，不能编写生产代码<br>
只可编写刚好无法通过的单元测试，不能编译也算无法通过<br>
只可编写刚好足以通过当前失败测试的生产代码<br>
保持测试代码整洁
测试代码不整洁，就会出现脏测试，无法覆盖全
测试代码和生产代码一样重要，同时迭代更新
测试能带来一切好处
预知测试缺陷
预知代码结构设计和架构的整洁<br>
整洁的测试
可读性
构造参数
操作测试数据（业务逻辑）
校验数据（例如：断言AssertEquals()）<br>
面向特定领域的语言
指的是提供一个API或者第三方包，要提供单元测试，方便他人使用
双重标准
测试代码和生产代码，在不同环境中，测试代码可能达不到生产代码，做的那么简洁，我们不应该强制要求测试代码标准
每个测试一个断言
如果因为分解代码，导致重复代码，应该放在基类
每个测试都只有一个概念
测试多个，应该对代码进行拆分<br>
F.I.R.S.T原则
自足校验
每个校验都应该用布尔值判断，而不是通过日志
味道与启发
注释
不恰当的信息
废弃的注释<br>
例如：废弃、过时、无关和不正确的注释
糟糕的注释
函数<br>
过多参数
输出参数
避免使用输出参数，如果必须修改就修改对象的状态
一般性问题
不正确的边界
忽视安全
消除重复
基类依赖于派生类<br>
基类不能因基类依赖派生类
死代码<br>
调用不到的代码必须删除，例如：if/case中代码
前后不一致
使用变量名字应该前后保持一致，便于阅读
不恰当使用静态变量
用多态替代 if/else和Switch/case
用命名常量代替魔法数值
避免否定条件<br>
否定条件比较难以理解,采用肯定条件
Java<br>
不要继承常量
Enum代替常量
导入包过多清单，采用通配符，例如：com.ycz.*
名称
采用描述性名称
名称应与抽象层级相符
使用标准命名
使用无歧义名称
避免编码
为作用较大范围的采用较长的名称<br>
测试
别略过测试<br>
测试应该快速
使用覆盖性工具，例如：idea约束条件，提示性错误
