认知篇
你写的每一行代码，都是你的名片
1 我们总是先要解决掉数量问题，然后才能解决掉质量问题? 看山不是山
2 看代码和写代码
比如说，“好”的代码应该：
容易理解；
没有明显的安全问题；
能够满足最关键的需求；
有充分的注释；
使用规范的命名；
经过充分的测试。
“坏”的代码包括：
难以阅读的代码；
浪费大量计算机资源的代码；
代码风格混乱的代码；
复杂的、不直观的代码；
没有经过适当测试的代码。
规范篇：
代码整理逻辑
代码起个好名字
为标识符提供附加的信息，赋予标识符现实意义。帮助我们理顺编码的逻辑，减少阅读和理解代码的工作量；
使代码审核变得更有效率，专注于更重要的问题，而不是争论语法和命名规范这类小细节，提高开发效率；
提高代码的清晰度、可读性以及美观程度；
避免不同产品之间的命名冲突。
1 要有准确的意义 2 严格遵守命名规范 3 可读性优先
代码段
保持代码块的单一性，一个代码块只能有一个目标 注意代码块的完整性 代码块数量要适当，不超过25行 适当使用空白空间 遵循基本的换行原则
- 每行代码字符数的限制。
- 如果一行不足以容纳一个表达式，就需要换行；
- 一般的换行原则包括以下五点。
- []在逗号后换行。
- []在操作符前换行。
- []高级别的换行优先。
- []新的换行与上一行同级别表达式的开头对齐。
- []如果上述规则导致代码混乱或者代码太靠右，使用 8 个空格作为缩进（两个缩进单位）。 注释 几种常见注释类型 第一种类型，是记录源代码版权和授权的 * Copyright (c) 2018, FirstName LastName. All rights reserved 第二种类型，是用来生成用户文档的 第三种类型，是用来解释源代码的
异常处理
非正常异常（Error）： 这类异常的命名以 Error 结尾，比如 OutOfMemoryError，NoSuchMethodError。这类异常，编译器编译时不检查，应用程序不需要处理，接口不需要声明，接口规范也不需要纪录；
运行时异常（RuntimeException）： 这类异常的命名通常以 Exception 结尾，比如 IllegalArgumentException，NullPointerException。这类异常，编译器编译时不检查，接口不需要声明，但是应用程序可能需要处理，因此接口规范需要记录清楚；
非运行时异常： 除了运行时异常之外的其他的正常异常都是非运行时异常，比如 InterruptedException，GeneralSecurityException。和运行时异常一样，命名通常以 Exception 结尾。这类异常，编译器编译时会检查异常是否已经处理或者可以抛出，接口需要声明，应用程序需要处理，接口规范需要记录清楚。
不要使用异常机制处理正常业务逻辑；
异常的使用要符合具体的场景；
具体的异常要在接口规范中声明和标记清楚。
编码规范
两种思维：
自主模式（快系统）和控制模式（慢系统）。自主模式的运行是无意识的、快速的、不怎么耗费脑力； 控制模式需要集中注意力，耗费脑力，判断缓慢，如果注意力分散，思考就会中断。
识别模式 猜测模式 记忆模式
编码规范的检查清单
代码是按照编码指南编写的吗?
代码能够按照预期工作吗?
文件是不是在合适的位置?
支撑文档是不是充分?
代码是不是易于阅读、易于理解?
代码是不是易于测试和调试?
有没有充分的测试，覆盖关键的逻辑和负面清单?
名字是否遵守命名规范?
名字是不是拼写正确、简单易懂?
名字是不是有准确的意义?
代码的分块是否恰当?
代码的缩进是否清晰、整洁?
有没有代码超出了每行字数的限制?
代码的换行有没有引起混淆?
每一行代码是不是只有一个行为?
变量的声明是不是容易检索和识别?
变量的初始化有没有遗漏?
括号的使用是不是一致、清晰?
源代码的组织结构是不是一致?
版权信息的日期有没有变更成最近修改日期?
限定词的使用是不是遵循既定的顺序?
有没有注释掉的代码?
有没有执行不到的代码?
有没有可以复用的冗余代码?
复杂的表达式能不能拆解成简单的代码块?
代码有没有充分的注释?
注释是不是准确、必要、清晰?
不同类型的注释内容，注释的风格是不是统一?
有没有使用废弃的接口?
能不能替换掉废弃的接口?
不再推荐使用的接口，是否可以今早废弃?
继承的方法，有没有使用 Override 注解?
有没有使用异常机制处理正常的业务逻辑?
异常类的使用是不是准确?
异常的描述是不是清晰?
是不是需要转换异常的场景?
转换异常场景，是不是需要保留原异常信息?
有没有不应该被吞噬的异常?
外部接口和内部实现有没有区分隔离?
接口规范描述是不是准确、清晰?
接口规范有没有描述返回值?
接口规范有没有描述运行时异常?
接口规范有没有描述检查型异常?
接口规范有没有描述指定参数范围?
接口规范有没有描述边界条件?
接口规范有没有描述极端状况?
接口规范的起草或者变更有没有通过审阅?
接口规范需不需要标明起始版本号?
产品设计是不是方便用户使用?
用户指南能不能快速上手?
用户指南的示例是不是可操作?
用户指南和软件代码是不是保持一致?
