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

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

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

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

　　1、对局域变量（local variables）、参数（method arguments）、字段（fields）这三种变量的命名没有区分：

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

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

　　示例1：

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

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

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

　　● 参数定义时名字加前缀a

　　● 字段定义时名字加前缀f

　　● 局域变量定义时不加任何前缀

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

　　你可能反对示例2中的风格，反对过时了的匈牙利符号，但是我认为反对是错误的，因为匈牙利符号能详细说明信息的类型。

　　上面的命名约定区分了类型。而且这样做分清了字段、变量和局域变量，这是两种完全不同的概念。

　　这种命名约定的方式并不像看起来那么微不足道：当这些约定用在程序编码中时，会大大降低理解的难度，因为你可以不需要先分辨这些变量，省去不少时间。

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

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

　　com.blah.action
　　com.blah.dao
　　com.blah.model
　　com.blah.util

　　也就是说，把具有同样特征或者功能的类划分到了不同的包里。因为成员的属性对其他成员应该是可见的，这就意味着几乎应用程序中所有的类都是公共的。实际上，这种按层次划分包的方法完全扔掉了Java的包内私有。包内私有应该彻底不使用。现在，包内私有是Java程序语言中设计者的默认作用域。这种包的划分习惯也违反了面向对象编程的核心原则之--尽量保持私有以减少影响,因为这种习惯强迫你必须扩大类的作用域。由于一些奇怪的原因，一些Java组织不赞成这种命名，似乎不公正的。