Clean Code
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
简洁的代码应该易于理解 —— 团队中的每个人都能轻松理解。简洁的代码可以被其他开发者阅读和改进,而不仅仅是其原作者。理解性强的代码具有可读性、可变更性、可扩展性和可维护性。
General rules
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
通用规则
- 遵循标准规范。
- 保持简单,越简单越好。尽量减少复杂性。
- 童子军规则。离开时让营地比你到来时更干净。
- 始终找到问题的根本原因。总是寻找问题的根本原因。
Design rules
- Keep configurable data at high levels.
- Prefer polymorphism to if/else or switch/case.
- Separate multi-threading code.
- Prevent over-configurability.
- Use dependency injection.
- Follow Law of Demeter. A class should know only its direct dependencies.
设计规则
- 将可配置的数据放在高层次。
- 优先使用多态而不是 if/else 或 switch/case。
- 将多线程代码分离。
- 防止过度配置。
- 使用依赖注入。
- 遵循迪米特法则(最少知识原则)。一个类应该只知道它的直接依赖关系。
Understandability tips
- Be consistent. If you do something a certain way, do all similar things in the same way.
- Use explanatory variables.
- Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
- Prefer dedicated value objects to primitive type.
- Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.
- Avoid negative conditionals.
理解性建议
- 保持一致性。如果你以某种方式做某事,那么对所有类似的事情都使用相同的方式。
- 使用解释性变量。
- 封装边界条件。边界条件很难跟踪,应将其处理集中在一个地方。
- 优先使用专用的值对象而不是原始类型。
- 避免逻辑依赖。不要编写依赖于同一个类中其他部分的方法。
- 避免负面条件。
Names rules
- Choose descriptive and unambiguous names.
- Make meaningful distinction.
- Use pronounceable names.
- Use searchable names.
- Replace magic numbers with named constants.
- Avoid encodings. Don't append prefixes or type information.
命名规则
- 选择描述性和明确的名称。
- 具有有意义的区分。
- 使用可发音的名称。
- 使用可搜索的名称。
- 用命名常量代替魔术数字。
- 避免编码。不要添加前缀或类型信息。
Functions rules
- Small.
- Do one thing.
- Use descriptive names.
- Prefer fewer arguments.
- Have no side effects.
- Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag.
函数规则
- 保持简短。
- 只做一件事。
- 使用描述性名称。
- 优先使用更少的参数。
- 不产生副作用。
- 不要使用标志参数。将方法分成几个独立的方法,客户端可以不使用标志来调用。
Comments rules
- Always try to explain yourself in code.
- Don't be redundant.
- Don't add obvious noise.
- Don't use closing brace comments.
- Don't comment out code. Just remove.
- Use as explanation of intent.
- Use as clarification of code.
- Use as warning of consequences.
注释规则
- 始终尽量通过代码来解释自己。
- 不要重复。
- 不要添加明显的噪音。
- 不要使用闭合括号注释。
- 不要注释掉代码。直接删除。
- 用于解释意图。
- 用于澄清代码。
- 用于警告后果。
Source code structure
- Separate concepts vertically.
- Related code should appear vertically dense.
- Declare variables close to their usage.
- Dependent functions should be close.
- Similar functions should be close.
- Place functions in the downward direction.
- Keep lines short.
- Don't use horizontal alignment.
- Use white space to associate related things and disassociate weakly related.
- Don't break indentation.
源代码结构
- 垂直分离概念。
- 相关的代码应垂直密集出现。
- 在使用附近声明变量。
- 相关的函数应靠近。
- 相似的函数应靠近。
- 将函数放在向下的方向。
- 保持行简短。
- 不要使用水平对齐。
- 使用空白来关联相关的事物并分离弱相关的事物。
- 不要破坏缩进。
Objects and data structures
- Hide internal structure.
- Prefer data structures.
- Avoid hybrids structures (half object and half data).
- Should be small.
- Do one thing.
- Small number of instance variables.
- Base class should know nothing about their derivatives.
- Better to have many functions than to pass some code into a function to select a behavior.
- Prefer non-static methods to static methods.
对象和数据结构
- 隐藏内部结构。
- 优先使用数据结构。
- 避免混合结构(半对象半数据)。
- 应该小而简单。
- 只做一件事。
- 实例变量的数量应少。
- 基类不应了解其派生类。
- 比起传递代码到函数中选择行为,更好的是有多个函数。
- 优先使用非静态方法而不是静态方法。
Tests
- One assert per test.
- Readable.
- Fast.
- Independent.
- Repeatable.
测试
- 每个测试只包含一个断言。
- 可读性强。
- 运行速度快。
- 互相独立。
- 可重复执行。
Code smells
- Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
- Fragility. The software breaks in many places due to a single change.
- Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
- Needless Complexity.
- Needless Repetition.
- Opacity. The code is hard to understand.
代码异味
- 僵化性。软件难以更改。一个小的更改会引发一连串的后续更改。
- 脆弱性。软件在多个地方因单个更改而崩溃。
- 不可移植性。由于涉及的风险和高昂的成本,无法在其他项目中重用部分代码。
- 无谓的复杂性。
- 无谓的重复。
- 模糊性。代码难以理解。