整洁干净的代码之道－自己翻译太烂请大家先别浪费时间看

下面是自己翻译的，连自己都读不懂，所以请各位路过的就不要再浪费时间往下读了，要不然得骂我了。只为自己挂这里，后面修改好了大家再看。

翻译自clean-code-2.1.pdf

说明：+表示极力提倡的做法 -表示极力避免的做法

Why Clean Code

整洁干净的代码，可以让人容易理解。容易理解的话，就可读性好，容易修改，容易扩展和维护。这样才可以保证一个项目可以长期存活下去。

在整个软件产品的生命周期中，在项目一开始就遵守书写干净整洁代码的习惯，是一个保证未来改变的成本是一个常量的投资。因此，一开始就按照编写干净整洁的代码的成本会比直接很快的写出脏乱的代码高的多，但是这些开始投入的成本很快就可以找回来。尤其是如果你清楚，软件成本大多数集中是在软件维护期间。不干净的代码会导致技术债务随着时间而不断累积，如果没有重构为干净代码的话。有一些其它的原因导致技术债务比如坏的进度或缺乏文档，但不干净的代码是主要原因。结果你应变的能力下降了。

In Clean Code, Bugs Cannot Hide

在干净的代码中，藏不住bug。当修改现有代码时，大多数软件缺陷被引入。背后的原因是，开发者改变代码不能完全把握改变所带来的后果。干净整洁的代码通过使代码尽可能容易的理解来最小化引入缺陷的风险。

Principles 准则

Loose Coupling松散偶合+

在两个类（组件或模块）中，当其中一个中使用另一个时偶合就产生了。当两个彼此之间相互知道的越少，偶合会越松散。相比强偶合的组件，一个对于其环境而言是松散偶合的组件更容易改变或被替换掉。

High Cohesion高内聚+

聚合度是衡量一个整体的各个部分聚合为整体的程度。一个类中的方法和字段和一个组件中的各个类应该是高内聚的。类和组件中的高内聚使得代码结构与设计更简单，更容易理解。

Change is Local 局部修改+
When a software system has to be maintained, extended and changed for a long time, keeping change local reduces involved costs and risks. Keeping change local means that there are boundaries in the design which changes do not cross. 

当一个软件系统要长期被维护、扩展和修改，保持局部修改可以减少牵涉的成本和风险。保持局部修改意味着修改不会跨越设计的界限。

It is Easy to Remove 易于削除+
We normally build software by adding, extending or changing features. However, removing elements is important so that the overall design can be kept as simple as possible. When a block gets too complicated, it has to be removed and replaced with one or more simpler blocks.

我们常规通过增加、扩展或修改功能特性来构造软件。然而，为保持整体设计尽可能简单，能去掉某个或某些部分也很重要。当一个功能块太过复杂，它就得被拿掉，然后替换为一个或多个简单的功能块。

Understandability 可理解性

Consistency +一致性
If you do something a certain way, do all similar things in the same way: same variable name for same concepts, same naming pattern for corresponding concepts. 

如果用一种确定的的方式做一些事，那么类似的事都采用同样的方式。相同的概念用相同的变量名，相对应的概念用相同的命名模式。

Use Explanatory Variables + 自解释变量
Use locals to give steps in algorithms names.

Encapsulate Boundary Conditions +封装边界条件
Boundary conditions are hard to keep track of. Put the processing for them in one place, e.g. nextLevel = level + 1;

Prefer Dedicated Value Objects to Primitive Types + 尽量用专门值对象而不是基本类型
Instead of passing primitive types like strings and integers, use dedicated primitive types: e.g. AbsolutePath instead of string.

Poorly Written Comment – 不良好的注释书写
Comment does not add any value (redundant to code), is not well formed, not correct grammar/spelling.

注释没有意义，格式不良好，语法、拼写不正确

Obscured Intent – 不清晰的意图
Too dense algorithms that lose all expressiveness. 

太紧凑的失去表达能力的算法

Obvious Behaviour Is Unimplemented – 明显行为没有实现
Violations of “the Principle of Least Astonishment”. What you expect is what you get.

违反最小xx原则。你期待什么，你得到什么。

Hidden Logical Dependency – 隐藏逻辑依赖
A method can only work when invoked correctly depending on something else in the same class, e.g. a DeleteItem method must only be called if a CanDeleteItem method returned true, otherwise it will fail.

一个方法只应该在同一个类中依赖其它部分工作。

Methods

Methods Should Do One Thing +方法只做一件事
Loops, exception handling, …encapsulate in sub-methods. 

循环，异常处理等等封装在子方法中

Methods Should Descend 1 Level of Abstraction +
The statements within a method should all be written at the same level of abstraction, which should be one level below the operation described by the name of the function.

Method with Too Many Arguments – 方法带太多参数
Prefer fewer arguments. Maybe functionality can be outsourced to a dedicated class that holds the information in fields. 

尽可能传递更少的参数。或许

Method with Out/Ref Arguments –
Prevent usage. Return complex object holding all values, split into several methods. If your method must change the state of something, have it change the state of the object it is called on.

避免使用。返回持有所有值的复杂对象，就要拆分为数个方法。如果你的方法必须修改一个东西的状态，它就改变被调用的对象的状态。

Selector / Flag Arguments – 选择器/标记参数
public int Foo(bool flag) Split method into several independent methods that can be called from the client without the flag. 

拆分方法为多个可以被调用的不用标记的独立方法

Inappropriate Static – 不合适的静态
Static method that should be an instance method 

静态方法应该是实例方法

Source Code Structure 源代码结构

Vertical Separation + 垂直分离
Variables and methods should be defined close to where they are used. Local variables should be declared just above their first usage and should have a small vertical scope.

变量和方法应该被定义在离使用它们最近的地方。局部变量应该刚好在第一次使用它们之前才声明，并且只在一个小范围内。

Nesting + 嵌套
Nested code should be more specific or handle less probable scenarios than unnested code.

嵌套代码应该比非嵌套代码更专门或处理更少的场景

Structure Code into Namespaces by Feature + 结构化到命名空间
Keep everything belonging to the same feature together. Don't use namespaces communicating layers. A feature may use another feature; a business feature may use a core feature like logging.