《代码整洁之道 》第五章 格式

第五章 格式

你应该保持良好的代码格式。你应该选用一套管理代码格式的简单规则，然后贯彻这些 规则。如果你在团队中工作，则团队应该一致同意采用一套简单的格式规则，所有成员都要遵守。使用能帮你应用这些格式规则的自动化工具会很有帮助。

5.1 格式的目的

代码格式关乎沟通，沟通是开发者的头等大事。
“让代码能工作”不一定是开发者的头等大事，你今天编写的功能，很可能明天就要修改了，但是代码的可读性却会对以后可能发生的修改行为产生深远影响。原始代码修改之后很久，其代码风格和可读性仍会影响到可维护性和扩展性，即使你的代码已经不存在了，但是你的风格和律条仍然存活下来。

5.2 垂直格式

源代码文件该有多大呢？

5.2.1 向报纸学习

写得好的报纸文章，从上往下读取，顶部有个头条，告诉你主题，第一段是故事大纲，给出粗线条概述，接着读下去，细节增加。
代码文件也要这样，名称简单一目了然，文件最顶部给出高层次的概念和算法，细节再往下逐次展开。
报纸由许多文章组成，多数短小精悍。

5.2.2 概念间垂直方向上的区域

代码都是从上往下，从左往右阅读，每个表达式或者子句，应该使用空白行隔开。
5-1为例，在封包声明、导入声明和每个函数之间，都有空白行隔开，每个空白行都是一条线索，表示出新的独立概念。

代码5-2 的格式就很难阅读，像一堆乱麻

5.2.3 垂直方向上的靠近

空白行隔开了概念，靠近的代码行则表示了他们的关系紧密。
代码5-3的阻塞隔断了两个实体间的变量联系

5.2.4 垂直的距离

你是否试过在某个类摸索，从一个函数跳到另一个函数，想弄清楚他们的逻辑和关联，最后却被搞糊涂了。花时间和精力记住那些代码碎片在哪里，这是不值得的。
关系密切的概念应该靠近，不要把关系密切的概念放在不同的文件之中。
比如变量声明就应该靠近其使用位置。

5.2.5 垂直的顺序

一般而言，我们想自上向下展示函数调用依赖顺序。也就是说，被调用的函数应该放在 执行调用的函数下面。这样就建立了一种自顶向下贯穿源代码模块的良好信息流。

5.3 横向格式

一行代码应该多宽呢？

5.3.1 水平方向上的区域与靠近

我们使用空格字符将彼此紧密相关的事物连接到一起，也用空格字符把相关性较弱的事物分隔。

5.3.2 水平对齐

在汇编或者c、c++的人，会把会极力对齐，大概会这样

5.3.3 缩进

源文件是一种继承结构，而不是大纲结构。其中涉及到 文件、文件里面的类，类中的方法、方法中的代码块。代码块中还有代码块。这种代码块的每个层级都圈出一个范围。
要让这种范围式的继承结构可见，我们依源代码行在继承结构中的位置对源代码行做缩进处理。
这样是很难阅读的：

违反缩进原则

5.3.4 空范围

有时，while 或for语句的语句体为空，如下所示。我不喜欢这种结构，尽量不使用。如果无法避免，就确保空范围体的缩进，用括号包围起来。很多次被静静安坐在与while 循环语句同一行末尾的分号所欺骗。除非你把那个分号放到另一行再加以 缩进，否则就很难看到它。

5.4 团队规则

每个程序员都有自己喜欢的格式规则，但如果在一个团队中工作，就是团队说了算。
记住，好的软件系统是由一系列读起来不错的代码文件组成的。它们需要拥有一致和顺畅的风格。读者要能确信，他们在一个源文件中看到的格式风格在其他文件中也是同样的用法。绝对不要用各种不同的风格来编写源代码，这样会增加其复杂度。

5.5 鲍勃大叔的格式规则

可以把这段代码看做是展示如何把代码写成最好的编码标准文档的范例。