代码整洁之道——有意义的命名（持续更新中）

我们给变量、参数、类、包，源代码和源代码所在目录命名，也给jar文件、war文件和ear文件命名。

We name variables, parameters, classes, packages, source code, and the directory where the source code resides, as well as jar files, war files, and ear files.

命名应该遵循什么规则：

What rules should be followed for naming:

名副其实 Worthy of the name

选个好名字需要花时间，但省下来的时间比花掉的多，一旦发现有更好的名称就应该换掉旧的，这样读你代码的人（包括自己）都会更开心。

Choosing a good name takes time, but it saves more time than it takes. Replace the old one as soon as you find a better name, and the people reading your code (including yourself) will be happier.

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

The name of a variable, function, or class should tell you why it exists, what it does, and how it should be used. If the name needs to be annotated, it's not really worth of the name.

避免误导 To avoid misleading

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

别用accountList来命名一组账号，用accountGroup或者bunchOfAccount，甚至直接用accounts都会好一些。

提防使用外形太相似的词。

应该以同样的方式拼写出同样的概念，这有益于开发工具的自动代码补全选择。

不要用小写字母l和大写字母O作为变量名，和常量“壹”和“零”太像。

Programmers must avoid leaving false clues that hide the intent of the code and avoid using words that contradict it.

Instead of naming a group of accounts accountList, use accountGroup or bunchOfAccount, or even use accounts directly.

Beware of words that are too similar in appearance.

The same concepts should be spelled out in the same way, which benefits the development tool's automatic code completion selection.

Don't use lowercase l and uppercase O for variable names, which are too similar to constants "one" and "zero".

做有意义的区分

使用读得出来的名称

使用可搜索的名称

避免使用编码

    匈牙利语标记法

    成员前缀

    接口和实现

避免思维映射

类名

方法名

别扮可爱

每个概念对应一个词

别用双关语

使用解决方案领域名称

使用源自所涉问题领域的名称

添加有意义的语境

不要添加没用的语境

读代码时也应该遵循这些规则去重命名