代码整齐之道(第5章节)--格式
当有人检察底层代码实现时，我们希望他们为其整齐、一致及所感知到的对细节的关注而震惊。我们希望他们高高扬起眉毛，一路看下去。我们希望他们感受到那些为之劳作的专业人士们。但若他们看到的只是一堆像是由酒醉的水手写出的鬼画符，那他们多半会得出结论，认为项目其他任何部门也同样对细节漫不经心。你应该保持良好的代码格式。你应该选用一套管理代码格式的简单规则，然后贯彻这些规则。假如你在团队中工作，则团队应该一致同意采用一套简单的格式规则，全部成员都要遵从。使用能帮你应用这些格式规则的自动化工具会很有资助。
5.1：格式的目的
先明确一下，代码格式很紧张。代码格式不可忽略，必须严厉对待。代码格式关乎沟通，
而沟通是专业开辟者的头等大事。
大概你认为“让代码能工作”才是专业开辟者的头等大事。然而，我希望本书能让你抛
掉那种想法。你今天编写的功能，极有可能在下一版本中被修改，但代码的可读性却会对以
后可能发生的修改行为产生深远影响。原始代码修改之后很久，其代码风格和可读性仍会影
响到可维护性和扩展性。即便代码已不复存在，你的风格和律条仍存活下来。
那么，哪些代码格式相关方面能帮我们最好地沟通呢?
5.2.1 向报纸学习
想想看写得很好的报纸文章。你从上到下阅读。在顶部，你渴望有个头条，告诉你故事主
题，好让你决定是否要读下去。第一段是整个故事的大纲，给出粗线条概述，但隐藏了故事细
节。接着读下去，细节渐次增加，直至你了解全部的日期、名字、引语、说法及其他细节。
源文件也要像报纸文章那样。名称应当简单且一目了然。名称本身应该足够告诉我们是
否在正确的模块中。源文件最顶部应该给出高条理概念和算法。细节应该往下渐次展开，直
至找到源文件中最底层的函数和细节。
报纸由很多篇文章构成;多数短小干练。有些轻微长点儿。很少有占满一整页的。这样
做，
报纸才可用。倘使一份报纸只登载一篇长故事，其中充斥毫无组织的事实、日期、名字
等，没人会去读它。
5.2.2 概念间垂直方向上的区隔
几乎全部的代码都是从上往下读，从左往右读。每行显现一个表达式或一个子句，每组
代码行展示一条完备的思绪。这些思绪用空白行区隔开来。
在封包声明、导入声明和每个函数之间，都有空白行隔开。这条
极其简单的规则极大地影响到代码的视觉外貌。每个空白行都是一条线索，标识出新的独立
概念。往下读代码时，你的眼光总会停顿于空白行之后那一行。
5.2.3 垂直方向上的靠近
假如说空白行隔开了概念，靠近的代码行则暗示了它们之间的精密关系。以是，精密相
关的代码应该相互靠近。留意代码清单 5-3 中的解释是怎样割断两个实体变量间的接洽的。
/**代码清单 5-3*/
public class ReporterConfig {
/**
*The class name of the reporter listener
*/
private String mclassName;
/**
* The properties of the reporter listener
*/
private list<Property>m_properties = new ArrayList<Property>();
public void addProperty(Property property){
m_properties.add(property);
}
} 代码清单 5-4更易于阅读。它刚好“一览无遗”,至少对我来说是这样。我一眼就能看到,
这是个有两个变量和一个方法的类。看上面的代码时，我不得不更多地移动头部和眼球，才
能得到相同的理解度。
/**代码清单 5-4*/
public class ReporterConfig {
private String mclassName;
private list<Property>m_properties = new ArrayList<Property>();
public void addProperty(Property property){
m_properties.add(property);
}
} 5.2.5 垂直顺序
一样平常而言，我们想自上向下展示函数调用依赖顺序。也就是说，被调用的函数应该放在
执行调用的函数下面’。这样就创建了一种自顶向下贯穿源代码模块的良好信息流。
像报纸文章一样平常，我们指望最紧张的概念先出来,指望以包括最少细节的方式表述它们。
我们指望底层细节末了出来。这样，我们就能扫过源代码文件，自最前面的几个函数获知要
旨，而不至于沉溺到细节中。
5.3 横向格式
一行代码应该有多宽?要回答这个问题，来看看典型的步伐中代码行的宽度。我们再一次检
验7个差别项目。图5-2展示了这7个项目的代码行宽度分布情况。其中显现的规律性令人印象深刻，45 个字符左右的宽度分布尤为云云。实在，20~60的每个尺寸，都代表全部代码行数的
1%。也就是统共 40%!大概其余 30%的代码行短于 10个字符。记着，这是个对数标尺，以是图
中长于 80个字符部门的线性降落在实际情况中会极其可观。步伐员们显然更喜爱短代码行。
https://i-blog.csdnimg.cn/direct/8a13da04106f42148aef8c3a1b33f46a.png
这分析，应该尽力保持代码行短小。死守 80个字符的上限有点僵化，而且我也并不反对
代码行长度到达100个字符或120个字符。再多的话，大抵就是肆意妄为了。
遵照无需拖动滚动条到右边的原则。上限是 120个字符。
5.3.1 水平方向上的区隔与靠近
我们使用空格字符将彼此精密相关的事物连接到一起，也用空格字符把相关性较弱的事
物分隔开。
private void measureline(String line){
lineCount++;
int lineSize = line.length();
totalChars += lineSize;
linewidthHistogram.addLine(lineSize, lineCount);
recordwidestLine(linesize);
} 赋值操作符周围加上空格字符，以此到达强调目的。赋值语句有两个确定而紧张的要素:左边和右边。空格字符加强了分隔结果。
另一方面，不在函数名和左圆括号之间加空格。这是因为函数与其参数密切相关，假如隔开，就会显得互无关系。把函数调用括号中的参数逐一隔开，强调逗号，表现参数是相互分离的。
空格字符的另一种用法是强调其前面的运算符。
public class Quadratic{
public static double rootl(double a, double b, double c){
double determinant = determinant(a，b，c)i
return (-b + Math.sqrt(determinant)) / (2*a);
}
public static double root2(int a, int b, int c){
double determinant = determinant(a，b，c);
return (-b - Math.sqrt(determinant)) / (2*a);
}
private static double determinant(double a, double b, double c){
return b*b - 4*a*C;
}
} 看看这些等式读起来多舒服。乘法因子之间没加空格，因为它们具有较高优先级。加减
法运算项之间用空格隔开，因为加法和减法优先级较低。
不幸的是，多数代码格式化工具都会漠视运算符优先级，重新到尾采用同样的空格方式。
在重新格式化代码后，以上这些微妙的空格用法就消散殆尽了。
5.3.2 水平对齐
当我还是个汇编语言步伐员时’，使用水平对齐来强调某些步伐结构。开始用C、C++编
码，最终转向 Java后，我继续尽力对齐一组声明中的变量名，或一组赋值语句中的右值。我
的代码看起来大概是这样:
https://i-blog.csdnimg.cn/direct/435dc631720445bb9acf916c4919f149.png
我发现这种对齐方式没什么用。对齐，像是在强调不紧张的东西，把我的眼光从真正的
意义上拉开。例如，在上面的声明列表中，你会从上到下阅读变量名，而忽视了它们的类型。
同样，在赋值语句代码清单中，你也会从上到下阅读右值，而对赋值运算符视而不见。更麻
烦的是，代码自动格式化工具通常会把这类对齐消除掉。
以是，我最终放弃了这种做法。如今，我更喜欢用不对齐的声明和赋值，如下所示，因
为它们指出了重点。假如有较长的列表需要做对齐处理，那问题就是在列表的长度上而不是
对齐上。下例 FitNesseExpediter 类中声明列表的长度分析该类应该被拆分了。
https://i-blog.csdnimg.cn/direct/0efa07c87aab43dcb2ed1192926de20e.png
5.3.3 缩进
源文件是一种继承结构，而不是一种大纲结构。其中的信息涉及整个文件、文件中每个
类、类中的方法、方法中的代码块，也涉及代码块中的代码块。这种继承结构中的每一层级
都圈出一个范围，名称可以在其中声明，而声明和执行语句也可以在其中解释
要让这种范围式继承结构可见，我们依源代码行在继承结构中的位置对源代码行做缩进
处理。
5.3.4 空范围
有时，while或for 语句的语句体为空，如下所示。我不喜欢这种结构，尽量不使用。如
果无法避免，就确保空范围体的缩进，用括号困绕起来。我无法告诉你，我曾经多少次被静
静安坐在与 while 循环语句同一行末尾的分号所诱骗。除非你把那个分号放到另一行再加以
缩进，否则就很丢脸到它。
while (dis.read(buf, 0, readBufferSize) != -1)
;
5.4 团队规则
每个步伐员都有本身喜欢的格式规则，但假如在一个团队中工作，就是团队说了算.
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]