10年开发，聊聊代码规范

很多公司的招聘JD上都会写“具有良好的代码习惯和代码洁癖者优先考虑”，可见代码规范在团队协作中还是很看重的。

恰好最近给公司的项目做了一次不小的重构，看到很多不规范的代码，闲暇之时总结一下我所理解的代码规范。

代码是写给人看的

不知大家有没有想过，为什么代码规范要在JD中明确列出来？ 我认为就是这东西在很多团队中很重要但往往又都缺少，才需要明确列出来，而不会列比如：需要程序员打字速度快之类的技能要求。

程序员写代码就像我们学生时代写作文，语文里有的词组、语法，这些在编程语言里同样存在。但不同的是作文是写给人看的，人是有思想有情感的，好的文章不仅没有错别字、语法通畅、而且还讲究艺术形式。而代码是写给机器执行的，只要语法没毛病，编译能通过，机器就能读懂执行。

这正是有意思的地方，程序员写代码是脑力工作有充分的自由发挥的余地，而不是流水线作业。

但是，现在的软件开发早已不是一个人单打独斗了，我们要完成一个系统或功能往往都是团队合作的，写的代码很可能团队小伙伴之间会互相调试改动。如果你写的代码过于“高深晦涩、行云流水”，导致别的小伙伴要研究个半天才能看懂，那这岂不是降低了团队开发效率。要知道机器可不讲艺术，它只管快速执行。

什么是好的代码风格

我认为好的代码应该具备以下几个特点：

格式统一

就像写作文要求段落首行空两个字符一样，代码也应该有统一的格式。一个团队的成员应该都按照一个格式要求写代码，而不是你写你的风格，我写我的风格，然后大家互相吐槽对方写的不规范。

代码格式可以选择像CheckStyle这样的工具，配置好规范，在打包时检查，这样强制要求输出的代码风格是统一的，很多开源项目都是这么用的。

这里多说一句，不要因为看不顺眼而轻易的格式化别人的代码，可能会出现意想不到的惊喜哦！

逻辑清晰

不可否认，我们写的大部分代码都是将业务逻辑翻译成机器代码。如果一段代码写的过于复杂难懂，比如：冗长的方法实现、多层嵌套循环、复杂的条件表达式等。不仅别人看起来费劲，几个月后自己再回过头来看可能都要回忆半天。而且往往这样的代码在修改时很容易出bug。

易于重构

只要项目在迭代，代码重构就是持续存在的，在写代码时也要考虑未来重构的难度。比如：不要写魔法数字，有含义的常量都定义成静态变量；变量名尽量做到见名知意；方法要加注释；一个方法太长分步骤说明业务逻辑。

在重构时要注意全局搜一下是否还有别的地方引用到了，有些不规范的写法会把变量名、方法名之类的写死在代码中，导致Eclipse、IDEA修改不到。

合理的设计模式

23种设计模式都是前辈们总结出的精华，我们熟练掌握是有必要的，不仅要知道设计模式是怎么回事，还要知道具体在什么场景下引入设计模式既不会增加系统复杂度又能提高扩展性。但不要为了“炫技”让代码显得高大上而强引入设计模式。

利用工具

每个人都是不一样的个体，如果仅仅通过培训宣导，开发规范显然是无法保证的。工欲善其事，必先利其器。保证代码规范业界也有一些成熟的工具可以拿来当辅助。

比如上面提到的CheckStyle，还有findbug、PMD、Sonar、Fortify、JaCoCo之类的，都可以加入到部署流水线上，让工具自动检查，节省人力，保证质量。