四个有害的Java编码习惯

    对编程语言而言，好的编码风格不仅能在程序编写初期生成有效的框架编码，还可以让我们的编码更加清晰规范。但是，正如本文作者所说，一些Java程序的编码风格虽应用广泛，却会对编码的可维护性产生负面影响，对我们的编程有害。本文告诉你如何打破这种风格，重写这4个有害的编码风格，优化编码，提高可维护性。

程序中的编码风格让我们的编程工作变得轻松，特别是程序维护员，他们要经常阅读其他人编写的程序编码，这一点尤其突出。编码规范从根本上解决了程序维护员的难题；规范的编码阅读和理解起来更容易，也可以快速的不费力气的借鉴别人的编码。对将来维护你编码的人来说，你的编码越优化，他们就越喜欢你的编码，理解起来也就越快。

同样，高水平的编码风格（例如固定的封闭结构）目的在于改善设计和使编码更易于理解。事实上，最后有些人会认为改善设计和提高编码的易读性是一回事。

本文中你会看到一些流行的编码风格被面向读者的更易于接受的风格所替代。有人争论说这些风格都已经被大家广泛使用，不应该简单的为了达到读者的期望而抛弃。然而，读者的期待只是其中一方面的原因，不可能凌驾于所有因素之上。列出四种常见的问题：

1.对局域变量(local variables)、参数(method arguments)、字段(fields)这三种变量的命名没有区分:

对看编码的人来说，首先要弄清这些数据如何定义的？看一个类时，得弄清楚每个条目是局域变量？字段？还是参数？有必要使用一个简单的命名约定来定义这些变量，增加易读性。

很多权威机构规范过字段变量用以区分它与其它的变量，但这远远不够。可以把对字段的合理的命名约定逻辑也应用在参数上面。先看示例1：没有进行区分这三种变量的类定义，如下所示：

示例1：

1 public boolean equals (Object arg) {
2   if (! (arg instanceof Range)) return false;
3   Range other = (Range) arg;
4   return start.equals(other.start) && end.equals(other.end);
5 }

 在这个方法中，arg直接用argument的缩写，虽然大家一看就知道这是参数了，但这种命名方式却丢失了参数代表的对象本身 的含义。大家知道这 是参数，却不知道这是什么参数。如果方法的参数多一点，都按照arg1，arg2这样的方式命名，阅读代码  的时候很头疼。另外两个字段变量，start和 end，突然凭空而出，想一下才知道这应该是字段。当然，这个方法很短，造成的困难还不大，如果这个方法比较长的话，突然看到start和end两个变 量，一般会先在前面找一下是不是局部变量，然后才能确定是类的字段变量。

 这个问题貌似微不足道，但为什么要让代码阅读者花费额外时间在这些琐碎的问题上呢？如果有个方案能让代码阅读者一目了然的明白变量是那种变量，为什 么不采用呢？就如同Steve McConnell在 《代码大全》中说的:"让人费神去琢磨神秘杀人凶手这没有问题，但你不需要琢磨程序代码，代码是用来阅读的。

接下来看示例2，使用命名约定后对示例1重写以后的代码，用到的命名约定有：

• 参数定义时名字加前缀a
• 字段定义时名字加前缀f
• 局域变量定义时不加任何前缀

示例2：对变量类型进行区分

1 public boolean equals (Object aOther) {
2   if (! (aOther instanceof Range)) return false;
3   Range other = (Range) aOther;
4   return fStart.equals(other.fStart) && fEnd.equals(other.fEnd);
5 ｝

你可能反对示例2中的风格，反对过时了的匈牙利符号，但是我认为反对是错误的，因为匈牙利符号能详细说明信息的类型。
上面的命名约定区分了类型。而且这样做分清了字段、变量和局域变量，这是两种完全不同的概念。
这种命名约定的方式并不像看起来那么微不足道：当这些约定用在程序编码中时，会大大降低理解的难度，因为你可以不需
要先分辨这些变量，省去不少时间。

2.按层次划分包，而不是根据特征或功能划分

最常见的划分应用序就是按层次命名包：

一些框架推荐使用层层定义包的传统的方式做为包的命名方法：由于使用传统的包命名，开发者总能知道在哪个位置可以找到
这些项目，但是为什么避免人们这样做呢？使用另一种按特征定义包的风格，就不需要这种单调的操纵，因此，按特征定义完
全超越了任何其它命名约定。约书亚布洛赫在《高效的Java》一书中说到：区分一个设计好坏的唯一重要因素是模块内部隐藏
的数据和其它模块中涉及的实现过程的程度。

3.习惯用JavaBeans而不是不可变对象

不可变对象是构造后状态不改变。Scala的主要创造者Martin Odersky最近还称赞过这种不可变对象。在《高效的Java》一书

中，Joshua Bloch列举了大量实例支持使用不可变对象，并总结了很多优点。但他的意见，似乎很大程度上被忽略。大多数程
序使用JavaBeans来替代不可变对象。JavaBean明显要比不可变对象复杂的多，因为它的巨大的声明空间。粗略的讲，你可以
把JavaBean看作是与不可变对象完全相反的对象：它允许最大的可变性。
JavaBean常被用来做数据库记录的映射。假如你要从数据库记录集映射一行为对象，不考虑现有的持久化方案和框架，你会将
这个对象设计成什么样子？跟javabean相似呢还是完全不一样？

我认为会完全不一样，说明如下：

• 它不包含一个无参数构造方法（这一特征是javabean必备的。）。作者认为一个数据库记录的对象如果不包含任何数据是没有意义的。一个数据库表的所有字段都是可选的情况有多少？

• It would likely not have anything to say about events and listeners.(不太明白作者的意思)

• 它不强迫你用可变的对象。

• 它内部有一个数据验证机制。这样一个验证机制对大多数数据库应用非常重要。(记住对象的第一原则：一个对象应该同时封装数据和对数据的操作。在这种情况下，操作就是验证数据。)

• 数据验证机制可以给最终用户(end user)报错。

按照javabeans的说明，javabeans是用来解决特殊领域的问题:在图形界面程序的设计中充当小部件。说明中绝对没有提到数据库。但现在通常用javabean来做数据库记录的映射。从实际角度来讲，许多被广泛使用的框架要求应用程序使用JavaBeans（或者其它类似的规范）来映射数据库记录。这种滥用不利于编程者了解和使用不可变对象。

4.私有成员排在其它成员的前面

类成员的排序没有按照成员的作用域的大小排列，而是把private放在前面。
以前的好莱坞影片开头总是长篇的荣誉。同样地，大多数Java类把私有成员放在最前面。示例3给出这种风格的典型例子：

 1 public class OilWell implements EnergySource {
 2    private Long id;
 3    private String name;
 4    private String location;
 5    private Date discoveryDate;
 6    private Long totalReserves;
 7    private Long productionToDate;
 8 
 9    public Long getId() {
10       return id;
11    }
12    public void setId(Long id) {
13       this.id = id;
14    }
15 
16   //..elided
17 }

然而，如果把私有成员定义放在后面，读者阅读会更容易。因为人们认识一个事物的通常过程都是从一般到特殊，从抽象层次来说，是从高层次到低层次的认识过程。如果你倒过来的话，读者就不能从整体上把握事物，也不能抓住事物的本质，只能在一堆具体的片段中迷失。

整体的抽象让你忽略了细节。抽象的层次越高，你可以忽略越多的细节。读者阅读一个类时可以忽略的细节越多他会越高兴。脑袋里填充太多的细节是痛苦的，所以细节越少越好。因此，将私有成员放在最后会显得更富有同情心，因为这样阻止了不必要的细节显露给读者。

本来C++程序的习惯也是像Java一样把private成员放在最开始。然而，C++社区迅速的认识到这是一个有害的规范，这个规范现在已经被修正。这里给出一个经典的C＋＋风格指南里的注释：

同样，伦敦大学帝国学院关于C++的指面中也说到：把公有的部分放在前面，读者会更感兴趣阅读，然后是保护的部分，最后是私有的部分。

有人会持反对意见，认为读者可以使用程序文档来理解类，而不是直接看源代码。这种理由似乎不成立，因为程序文档中没有相关的实现细节，这时看源代码是很有必要的。

所有的技术文档，通常都把难理解的信息放在开头，比如抽象的学术论文。为什么Java不打破这种常规呢？把私有成员放在最开头部分看起来是不是打破常规的好习惯。这种习惯似乎是sun早期的编码规范造成的。

将代码按照javadoc的顺序编排是非常好的：首先是构造方法，然后是非私有方法，最后是私有部分和方法。这样读者阅读的时候很自然的从抽象层次的高向低运动。

本文所讲的是一些Java的不好习惯和风格需要改变。最终的目地是希望我们的代码易读性更强，让读者更易于理解。