规范【G1】好代码

目录

定义

特性

高内聚低耦合

可读性

命名

坏的代码

---

定义

衡量代码质量的唯一有效标准：WTF/min —— Robert C. Martin

任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。—— Martin Fowler

整洁的代码如同优美的散文。—— Grady Booch

 

特性

高内聚低耦合

• 开闭原则 OCP (The Open-Close Principle)
• 单一职责原则 SRP (Single Responsibility Principle)
• 依赖倒置原则 DIP (Dependence Inversion Principle)
• 最少知识原则 LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)
• 里氏替换原则 LSP (Liskov Substitution Principle)
• 接口隔离原则 ISP (Interface Segregation Principle)
• 组合/聚合复用原则 CARP (Composite/Aggregate Reuse Principle)

 

可读性

命名

大到项目名、包名、类名，小到方法名、变量名、参数名，甚至是一个临时变量的名称，其命名都是很严肃的事，好的名字需要斟酌。

• 名副其实       好的名称一定是名副其实的，不需要注释解释即可明白其含义的。
• 容易区分       好的名称容易区分 
• 可读的          名称一定是可读的，易读的，最好不要用自创的缩写，或者中英文混写
• 足够短          名称当然不是越长越好，应该在足够表达其含义的情况下越短越好。
• 格式             良好的代码格式也是提高可读性非常重要的一环，分为垂直格式和水平格式。
• 垂直格式      通常一行只写一个表达式或者子句。一组代码代表一个完整的思路，不同组的代码中间用空行间隔。
• 水平格式      要有适当的缩进和空格
•  团队统一
• 类和函数应短小，更短小
• 函数只做一件事（同一层次的事）
• 参数越少越好
• 别给糟糕的代码加注释，重构它
• 好的注释提供信息、表达意图、阐释、警告
• 删除掉注释的代码
• 错误处理很重要，但他不能搞乱代码逻辑
• 抛出异常时提供足够多的环境和说明，方便排查问题
• 特例模型可消除异常控制或者 null 判断
• 尽量不要返回 null ，不要传 null 参数

 

坏的代码

• 重复
• 函数过长、类过大、参数过长
•  发散式变化、霰弹式修改、依恋情结
• 数据泥团
• 过多的 if...else 或者使用 switch