关于编码规范（一）
好的编码习惯一定要尽早的养成，就象小孩要从小养成良好的生活习惯一样。好的生活学习习惯会对小孩的一生产生巨大的影响，编码规范对于开发人员和开发团队来说，效果也一样。因此对于一个开发团队来说，在一开始就确立一个好的编码规范，并且所有人都严格执行，比什么都重要。等到发现代码杂乱无章，无法很好的理解各自的代码时，再来推行一个编码规范就晚了，要么矫正的成本太高，要么就很难真正的推行下去。
那么一个什么样的编码规范才算是一个好的编码规范呢？一个好的编码规范应该包含有哪些内容，有哪些特点呢？
对命名和代码格式进行规范
一般的编码规范至少会规定各种命名方法(文件，类，方法，变量等)，以及如何格式化代码。这些当然重要，统一的命名规范和代码格式使整个项目的代码至少在外观上统一，有助于代码维护。坊间流行的命名方法和代码格式多种多样，有的人喜欢微软的匈牙利命名法，有的人喜欢JAVA风格的命名方法，有的人喜欢Unix风格的命名方法。关于各种命名法和代码格式优劣的争论从来没有停止过，其实命名规范的关键是使得代码有良好的可读性并且有一个统一的风格，仅此而已。具体使用哪一种并不重要，关键是自始至终的贯彻下去。关于命名还有一个值得注意的地方，就是命名一定要充分，要能表达命名主体(变量、方法、类等)的具体含义，不能是含混不清的，不要滥用缩写（除非大家公认的缩写，比如len代表length），尽量用完整的单词。现在的编辑器都支持自动补全，名字长一点，多几个字母没什么大不了，有意义，便于理解的命名对后继维护将带来很大的便利。
我见过很多在命名和代码格式方面规范的很细致，很“死板”的编码规范。有的甚至对注释的行数进行了硬性的规定(要求至少和代码数量相当)。我自己是最反感教条式的“八股文”。规范并不等同于教条，其实规范命名的本质是让代码更可读，达到这个目的也就OK了。因此能放宽的地方应该尽量放宽，让程序员有足够的自由度。由其是注释，注释的目的是对代码进行补充说明。换句话说，应该尽量的鼓励程序员写出不言自明的代码，写出不需要注释也可以轻松看懂的代码。在无法达到上述目的的时候，再用注释进行补充说明。（关于怎样写出不言自明的代码，我们在另一篇文章里介绍）注释一多，维护注释和代码的同步也不是件轻松的事，项目周期越长，这个问题越明显。
促进、引导程序员进行好的编程实践
好的编码规范会引导、促使或是“强迫”程序员使用一些好的编程实践。比如，对类或是方法的规模进行要求。庞大的类和方法一般都是代码缺乏良好划分和规划的结果，这样的代码即不利于理解，也不好维护。对类和方法的规模进行要求，至少会强迫程序员对代码进行思考，进行规划和拆分。经过这样的规划和拆分后的代码往往更利于重构和重用。
有的编码规范会明确的引入一些好的编程实践。比如，要求为所有的接口和重要的方法建立测试案例，以测试驱动的方式开发。(关于测试驱动开发(TDD)的好处，有机会单独写个文章来阐述)。有些会将代码重构的一些指导性原则列入到编码规范中。还有一些使用了私有架构的，也会结合具体的架构，对编码进行要求。比如有些私有架构自己实现了单根的对象层次和垃圾回收，这些对系统中类的实现都有特殊的要求。
（未完待续）