顺序中的编码作风让我们的编程工作变得轻松，特别是顺序维护员，他们要常常阅读其别人编写的顺序编码，这一点尤其突出。编码规范从根本上解决了顺序维护员的难题；规范的编码阅读和理解起来更容易，也可以快速的不费力气的自创别人的编码。对将来维护你编码的人来说，你的编码越优化，他们就越喜欢你的编码，理解起来也就越快。
同样，高水平的编码作风（例如固定的封闭构造）目的在于改善设计和使编码更易于理解。现实上，最初有些人会以为改善设计和提高编码的易读性是一回事。
本文中你会看到一些盛行的编码作风被面向读者的更易于接受的作风所替代。有人争论说这些作风都曾经被大家广泛运用，不应该简单的为了到达读者的期望而丢弃。但是，读者的期待只是其中一方面的原因，不可能凌驾于所有要素之上。列出四种罕见的问题：
1.对局域变量(localvariables)、参数(methodarguments)、字段(fields)这三种变量的命名没有区分:
对看编码的人来说，首先要弄清这些数据如何定义的？看一个类时，得弄清楚每个条目是局域变量？字段？还是参数？有必要运用一个简单的命名约定来定义这些变量，增加易读性。
很多权威机构规范过字段变量用以区分它与其它的变量，但这远远不够。可以把对字段的合理的命名约定逻辑也运用在参数下面。先看示例1：没有停止区分这三种变量的类定义，如下所示：
示例1：
public boolean equals (t arg)
if (! (arg instanceof Range)) return false;
Range other = (Range) arg;
return start.equals(other.start)end.equals(other.end);
在这个方法中，arg直接用argument的缩写，虽然大家一看就知道这是参数了，但这种命名方式却丢失了参数代表的对象自身的含义。大家知道这是参数，却不知道这是什么参数。如果方法的参数多一点，都按照arg1，arg2这样的方式命名，阅读代码的时候很头疼。另外两个字段变量，start和end，突然凭空而出，想一下才知道这应该是字段。当然，这个方法很短，形成的困难还不大，如果这个方法比拟长的话，突然看到start和end两个变量，普通会先在前面找一下是不是局部变量，然后才干确定是类的字段变量。
这个问题貌似微不足道，
璐唯丝但为什么要让代码阅读者破费额定时间在这些琐碎的问题上呢？如果有个方案能让代码阅读者一目了然的明白变量是那种变量，为什么不采用呢？就如同SteveMcConnell在《代码大全》中说的:"让人费神去揣摩神秘杀人凶手这没有问题，但你不需求揣摩顺序代码，代码是用来阅读的。
接上去看示例2，运用命名约定后对示例1重写以后的代码，用到的命名约定有：
参数定义时名字加前缀a
字段定义时名字加前缀f
局域变量定义时不加任何前缀
示例2：对变量类型停止区分
