一、 格式的目的
格式关乎沟通，代码格式很重要，必须严肃对待，因为你现在写的代码可能以后由其他人维护。
或许你认为“让代码工作”才是开发者的头等大事。然而，本书作者希望你抛弃这种想法。你现在所做的功能，极有可能在下一个版本中被修改，但代码的可读性却会对以后可能发生的修改产生深远的影响。
二、 垂直格式
源代码文件应该有多大？类应该有多大？短文件通常比长文件易理解，尽量让类文件代码行在500以下。
用大多数为200行、最长500行的单个文件构造出色的系统是可能的，尽管这并非不可违背的原则，也应该乐于接受。短文通常比长文件易于理解。
（1）向报纸学习
一篇好的报纸文章，内容是从上到下循序渐进的，第一段往往是故事的大纲，再往下阅读，细节才会渐次增加。
源文件也应该像读报纸那样，名称应当简单且一目了然，名称本身应该足够告诉我们是否在正确的模块中。最顶部应该给出高层次概念和算法，细节往下逐步展开。
（2）概念间垂直方向上的区隔
几乎所有代码都是从上往下读，从左往右读。每行展现一个表达式或一个子句。每组代码行展示一条完整的思路。这些思路用空白行区隔开。每个空白行都是一条线索，标识出新的独立概念。
如果抽调这两个空白行，代码的可读性会下降不少。
（3）垂直方向上的靠近
如果说空白行隔开了概念，靠近的代码则暗示了它们之间的紧密关系。所以，关系紧密的代码应该互相靠近。
举个例子，bad practice：
良好的实践：
良好的实践中，一眼就能看到这是有两个变量和一个方法的类。但是看bad practice代码的时候，要进行很大跨度的阅读才可。也间接说明了javadoc不是任何时候都是必要的。
（4）垂直距离
关系密切的概念应该互相靠近，显然，这条规则并不适用于分布在不同文件中的概念。除非有很好的理由，否则就不要把关系密切的概念放到不同的文件中。
对于那些关系密切、放置于同一源文件中的概念 ，应尽量避免读者在源文件中跳来跳去。
①变量声明
变量声明应该尽可能靠近使用位置。因为函数很短，本地变量应该在函数顶部出现。
②实体变量
实体变量应该在类的顶部声明。在设计良好的类中，它们会被大多数方法使用。
③相关函数
某个函数调用了另外一个，就应该把它们放到一起，而且调用者应尽可能放在被调用者上面。这样，程序就有了自然的顺序，极大的增强了整个模块的可读性。
④概念相关
概念相关代码应该放到一起，相关性越强，彼此之间的距离应该越短。举个例子：
这些函数有着极强的概念相关性。因为他们有着共同的命名模式，执行同一基础任务的不同变种。
⑤垂直顺序
一般而言，我们想自上而下展示函数调用依赖顺序，这样就建立了一种自顶向下贯穿代码模块的良好信息流。
三、 横向格式
一行代码应该多宽？应该尽量保持代码行短小，尽量不要让代码超过右侧屏幕。
（1）水平方向上的区隔与靠近
我们使用空格将彼此紧密相关的事物连接到一起，也用空格字符把相关性较弱的事物隔开。
①在赋值操作前后加上空格字符，加强左边和右边的分割效果。
int lineSize += 2;
+=运算符前后有空格。
②不要在函数名和左圆括号中间加空格，因为函数与其参数密切相关，如果分开，就会显得互无关系。
③函数调用括号中的参数用空格一一隔开，强调逗号，表示参数是互相分离的。
④在运算符周围加或不加空格来表示优先级。
（2）缩进
源文件是一种继承结构，而不是大纲结构。其中的信息涉及整个文件、文件中每个类、类中的方法、方法中的代码块，也涉及代码块中的代码块。这种继承结构中每一个层级都有一个范围，名称可以在其中声明，而声明和执行语句也可以在其中解释。
要让这种范围式继承结构可见，就需要缩进处理。在文件的顶层语句，例如大多数类声明，根本不缩进，类中的方法对应该类缩进一个层级。方法的实现相对方法的声明缩进一个层级。代码块的实现相对于其容器代码块缩进一个层级，以此类推。
（3）空范围
有时，while或者for语句的语句体为空，尽量不要使用这种结构，如果无法避免，就确保空范围体的缩进，用括号包围起来。
良好实践：
while (dis.read(buf, 0, readBufferSize) != -1) {
}
bad practice：
while (dis.read(buf, 0, readBufferSize) != -1) ;
为什么这是bad practice呢？因为很容易让人忽视掉最后的分号，误以为下面的语句在while循环里。
四、团队规则
一组开发者应该认同同一种风格，每个成员都应该采用那种风格。
记住，好的软件系统由一系列读起来不错的代码文件组成的。它们需要有一致和顺畅的风格。绝对不要使用各种不同的编码风格来编写源代码，这样会增加其复杂度。
五、附录，作者提供的格式规范code的范例
可以看到这份代码确实读起来很顺畅，让人看起来神清气爽。
满足垂直格式和横向格式中的细节。
参考
《代码整洁之道》
