The reading notes of Clean Code without coding part.

Chapter 1 Clean Code

让营地比你来时更干净

Make the camp cleaner than when you came

Chapter 2 Naming

变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。

程序员必须避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词。

人类长于记忆和使用单词。大脑的相当一部分就是用来容纳和处理单词的。单词能读得出来。人类进化到大脑中有那么大的一块地方用来处理言语，若不善加利用，实在是种耻辱。

类名和对象名应该是名词或名词短语，如Customer、WikiPage、Account和AddressParser。避免使用Manager、Processor、Data或Info这样的类名。类名不应当是动词。

方法名应当是动词或动词短语，如postPayment、deletePage或save。

给每个抽象概念选一个词，并且一以贯之。

The name of the variable, function, or class should already answer all the big questions. It should tell you why it exists, what it does, and how it should be used. If the name needs to be supplemented by a comment, it is not worthy of the name.

The programmer must avoid leaving false clues that hide the intention of the code. Words that are contrary to the original meaning should be avoided.

Humans are better at remembering and using words. A considerable part of the brain is used to contain and process words. The words can be read. Humans have evolved to the point where there is such a large area in the brain for processing speech. If it is not used well, it would be a shame.

Class names and object names should be nouns or noun phrases, such as Customer, WikiPage, Account, and AddressParser. Avoid using class names like Manager, Processor, Data, or Info. Class names should not be verbs.

The method name should be a verb or a verb phrase, such as postPayment, deletePage, or save.

Choose a word for each abstract concept and use it consistently.

Chapter 3 Function

函数应该做一件事。做好这件事。只做这一件事。

要确保函数只做一件事，函数中的语句都要在同一抽象层级上。

我们想要让每个函数后面都跟着位于下一抽象层级的函数，这样一来，在查看函数列表时，就能偱抽象层级向下阅读了。我把这叫做向下规则。

别害怕长名称。长而具有描述性的名称，要比短而令人费解的名称好。长而具有描述性的名称，要比描述性的长注释好。使用某种命名约定，让函数名称中的多个单词容易阅读，然后使用这些单词给函数取个能说清其功用的名称。

如果没有参数，就是小菜一碟。如果只有一个参数，也不太困难。有两个参数，问题就麻烦多了。如果参数多于两个，测试覆盖所有可能值的组合简直让人生畏。 输出参数比输入参数还要难以理解。读函数时，我们惯于认为信息通过参数输入函数，通过返回值从函数中输出。我们不太期望信息通过参数输出。

函数承诺只做一件事，但还是会做其他被藏起来的事。有时，它会对自己类中的变量做出未能预期的改动。有时，它会把变量搞成向函数传递的参数或是系统全局变量。无论哪种情况，都是具有破坏性的，会导致古怪的时序性耦合及顺序依赖。

重复可能是软件中一切邪恶的根源。

只要函数保持短小，偶尔出现的return、break或continue语句没有坏处，甚至还比单入单出原则更具有表达力。另外一方面，goto只在大函数中才有道理，所以应该尽量避免使用。

The function should do one thing. Do it well. Only do this thing.

To ensure that the function only does one thing, the statements in the function must be at the same level of abstraction.

We want each function to be followed by a function at the next level of abstraction, so that when viewing the function list, we can read the abstract level down. I call this the downward rule.

Don’t be afraid of long names. A long and descriptive name is better than a short and convoluted name. Long, descriptive names are better than long descriptive comments. Use a certain naming convention to make multiple words in the function name easier to read, and then use these words to give the function a name that can explain its function.

If there are no parameters, it is a piece of cake. If there is only one parameter, it is not too difficult. With two parameters, the problem is more troublesome. If there are more than two parameters, testing the combination of all possible values is daunting. Output parameters are more difficult to understand than input parameters. When reading a function, we are used to thinking that information is input to the function through parameters and output from the function through return values. We don’t expect information to be output through parameters.

The function promises to only do one thing, but it will still do other things that are hidden. Sometimes, it will make unexpected changes to variables in its own class. Sometimes, it turns variables into parameters passed to functions or system global variables. In either case, it is destructive and can lead to weird timing coupling and sequence dependence.

Repetition may be the root of all evil in software.

As long as the function is kept short, the occasional return, break or continue statement is not harmful, and even more expressive than the single-in-single-out principle. On the other hand, goto makes sense only in large functions, so it should be avoided as much as possible.

Chapter 4 Comment

带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样得多。与其花时间编写解释你搞出的糟糕的代码的注释，不如花时间清洁那堆糟糕的代码。

Clean and expressive code with a few comments is much more decent than fragmented and complex code with a lot of comments. Instead of spending time writing comments that explain the bad code you came up with, spend time cleaning up the bad code.

Chapter 5 Format

好的软件系统是由一系列读起来不错的代码文件组成的。它们需要拥有一致和顺畅的风格。

A good software system consists of a series of code files that read well. They need to have a consistent and smooth style.

Chapter 6 Object and Data Structure

……