daxue.sankuai.com/personal.ht…
好代码与坏代码
好代码
-
包组织合理
-
异常设计合理
-
函数短小
-
类单一职责
-
接口SOLID（单一职责、开闭原则、接口隔离、依赖反转、里氏替换）
-
命名见名知意
坏代码
-
复用难
-
难于变化：未做抽象，改一处要改很多地方
-
难于理解
-
难于测试和验证
命名的整洁
常见命名规范
-
匈牙利命名法
-
驼峰命名法
-
帕斯卡命名法
-
下划线命名法
常用Java命名规范
-
包名小写
-
类名帕斯卡（大驼峰）
-
变量、方法名（小驼峰）
-
常量、枚举大写
变量命名技巧
-
尽量避免使用单字母变量，避免i/j/k，使用pos/index
-
变量名长度适中，8-20字符之间
-
用词技巧
-
布尔：isDone
-
状态：if(need)
-
方法命名技巧
-
动词开头，createXXX
-
避免query/fetch/find/search混用，应由团队统一约定
-
避免get/set开头，避免和关键字冲突
类命名技巧
- 名词或名词结尾，如：OrderService，CancelCommand
包命名规则
-
公司：com.公司名.{业务线}.项目名.模块名
-
个人：priv.个人名.项目名.模块名
命名大数据网站（别人怎么命名）
类的整洁
-
单一职责
-
适当时候做类的拆分
-
功能复用优先考虑组合（has-a），而不是继承（is-a）
java不支持多重继承，所以把巧克力咖啡中的巧克力视为添加剂，添加剂和咖啡做组合
隔离改变
-
接口隔离原则：一个类对另一个类的依赖，应建立在最小接口上
-
迪米特法则：知识最小原则，一个对象对其他对象尽可能少的了解，不要与非直接类通讯
-
降低成员访问权限，通过final类、priavte属性方法去控制
-
属性get/set方法，而不是直接object.property的方式
-
-
开闭原则：通过新增代码实现新需求，而不是改已有代码
-
依赖倒置原则：依赖抽象，而不是具体的实现
函数的整洁
-
尽量使用零参数、一参数函数：越多越难理解
-
尽量避免三参数及以上：参数越多，覆盖所有可能的值的组合就越多
-
参数过多，就该封装成参数对象了
保持同一抽象层级
避免副作用
- 函数承诺只做一件事，不做其他被藏起来的事
异常替代返回码
减少深层次嵌套，异常可以从异常类派生出来，抽离try/catch块
分层处理 链式传播
异常只打印一次，包含每一层的信息和调用栈
正确使用受检异常和非受检异常
受检异常：Exception
非受检异常：Error、RuntimeException
使用异常的最佳实践
-
总是做一些清理工作：如catch住了异常之后，在finally内执行关闭链接的操作
-
不要忽略异常：catch住了之后要做一些处理
-
不要使用异常来控制流程：不要把业务逻辑写在异常捕获里
-
不要捕获Throwable类：（遇到Error放弃捕获即可）在应用中不应捕获Throwable类，Error石Throwable类的子类，应用抛出Errors的时候，一般都是不可恢复的情况
-
要在方法定义分句中，定义具体的异常：也就是不要直接throws Exception，而是throws一个具体的，如IOException等
异常会影响性能
- 尽量使用标准异常
2. 正确的包装异常类型
3. 避免在finally内再抛出异常，只在finally内打印错误信息或关闭资源
4. 不要在finally内return，finally内的值都会有被改写的可能性
注释的整洁
一致的布局、一致的风格
-
（java）优秀代码行数在200-500之间，供参考
-
行建议不超过80-120字符，长行换行
-
运算符号前断行
-
赋值符号之后断行
-
-
善用空行
相似的代码看上去要相似
概念相关代码放到一起
-
变量声明尽量靠近使用位置
-
A调用B，尽量放到一起，A放到B上边
-
相关性越强，距离越短
