编码规范那些思考

一、问与答

作为软件开发者，我们可以开发低等级的软件，但不能开发低质量的软件。

　　那么我们要怎么去保证开发出高质量的软件呢？这是我们一直关注的问题，而编码规范正是实施质量保证的第一步。

 

在网上，其实也有很多代码规范了，在官网上也有推荐的规范，可是为什么我们再这里还要这么麻烦制定一个属于自己的规范呢？

　　其实这也是一个畅谈的话题了，每一个公司甚至小到每一个项目，都有着自己的规范，只用适合自己公司或者当前项目的规范，才是最好的规范。当然，现在在这里，最重要的原因还是在于统一的问题。
　　在高质量的软件中，你可以看到“架构的概念完整性”与“底层实现”之间的关系。“实现”与“架构”必须是清晰一致的，这种内在的、固有的一致性，需要编码规范来维系。如果没有这种统一的约定，那么我们做出的东西可能会充斥着各种不同的风格，显得混乱且难以理解。团队成员之间可能很不理解彼此之间的想法，甚至是相互抨击。各种代码风格上的差异会不断扩大，而代码质量则不断下降。而且，团队成员会花费时间在理解不同编程风格之间的差异，而没有专注于真正应该解决的问题。这样的时间消耗是难以接受的。所以，在每一个高质量代码的背后，一定存在着一份优秀的编码规范。
　　然而，也必须认识到编码规范不是“神”。编码规范仅仅是一个全局性质的规范，它只不过是一种编程约定，不能解决更深层次的问题。就像一篇格式漂亮但内容糟糕的论文不能被发表一样，你不能仅靠一个规范来摆脱软件作坊。而且，在编码规范中不宜包含那些冗长的开发技巧。我认为，对于代码是最佳实践应该是代码审查所要解决的，应该避免将编码规范写成一部关于重构的教科书。

 

您是否有因代码杂乱冗余而心生厌恶，您是否有过因代码晦涩难懂而抓狂，您是因代码低级的逻辑错误而愤概，您是否因代码结构不合常规而需要到处查找，您是否因看到几百甚至上千行代码的方法而望洋兴叹，您是否因代码缺少注释而猜测以及花很多时间去理清楚前后逻辑？

　　苦逼的我在这个星期阅读公司里面之前的项目代码的时候，全部都遇到过了。本身一个逻辑很简单的东西，我花的时间竟然比看jdk线程模块还要多，让我真的很惊讶，今天我到回去再看了下jdk的源代码，有了一个很重大的发现。也就是下面的的问题所在。

 

代码规范没有什么用处。这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率的东西？

　　通过查看jdk的源代码，你可以看到，如此多的编码规范—缩进，命名，文件结构，注释风格—这一切让人出乎意料的能够轻松的阅读任意一段代码，并轻易的看懂它们。
　　震惊了吗？规范本身是一个微不足道的东西，但它们却起到了这么大的作用。当你发现只通过看程序的基本语法结构就能读懂一段代码，这种时间上的节省不能不让人震撼！

 

当你按照某种编码规范进行编程时，必然会有某些地方让你摇头不爽，那么这规范真的不行吗？

　　肯定会在某些地方你的编码风格会优于这些规范。但是，这不重要。在某些地方，编码规范也有优于你的编程风格的时候。但是，这也不重要。只要这规范不是完全的不可理喻，在程序的可理解性上得到的好处会大大的补偿你的损失。
　　要是真的不可理喻怎么办？提出来，大家一起商量解决方法。

 

这个代码我只在这里用到，别人是用不到的，也不会给别人用或者修改的了，所以就不用按照规范改了吧？

　　相信很多人都会这么想吧，但是希望大家能够记住这么一句话。代码不是一次性的，它需要重复的修改和重构，为未来写点代码。这句话可能大家会有疑问，什么叫做为未来写点代码？简单说吧，如果你现在的代码写的不好，然后后期维护的时候，不可读，不可维护、不可拓展，那你是否就要重新写一次这些功能的代码，做重复的工作？但是如果现在我们按规范，写好了高质量的代码，以后就能直接用，从而减少了工作量，这样，算不算为未来写点代码了呢？相信大家能懂的。

 二、概述

1.编写目的
   1) 为规范软件开发人员的代码编写提供参考依据和统一标准
   2) 在项目开发过程中的注意事项以及编码规范，旨在提升代码的可读性与可维护性，同时减少代码出错的机会。

2.编码规范的好处

   1) 提高可读性 “任何一个人都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。”编码规范，帮助我们写出人类容易理解的代码，它为我们提供了最基本的模板，良好的编码风格，使代码具有一定的描述性，可以通过名字来获取一些需要IDE才能得到的提示，如可访问性、继承基类等

   2) 统一全局，促进团队协作 开发软件是一个团队活动，而不是个人的英雄主义。编码规范，要求团队成员遵守这一统一的全局决策，这样成员之间可以轻松地阅读对方的代码，所有成员正以一种清晰而一致的风格进行编码。而且，开发人员也可以集中精力关注他们真正应该关注的问题——自身代码的业务逻辑，与需求的契合度等局部问题。

   3) 有助于知识传递，加快工作交接 风格的相似性，能让开发人员更迅速，更容易理解一些陌生的代码，更快速地理解别人的代码。因为，他和你的代码风格是一样的，你没有必要对他的一些个性化风格进行揣测。这样的好处是开发人员可以很快的接手项目组其他成员的工作，快速完成工作交接。 

   4) 减少名字增生，降低维护成本 在没有规范的情况下，和容易为同一类型的实例起不同的名字。对于以后维护这些代码程序员来说会产生疑惑

   5) 强调变量之间的关系，降低缺陷引人的机会 命名可以表示一定的逻辑关系，是开发人员在使用时保持警惕，从而一定程度上减少缺陷被引人的机会

   6) 提高程序员的个人能力 不可否认，每个程序员都应该养成良好的编码习惯，而编码规范无疑是教材之一。从一个程序员的代码本身能看出很多东西。所以，即便是为了自身发展，作为程序员也没有理由抵制这种规则的存在。你可能没有认识到，我们正默默地得益于编码规范。

三、感谢语

　　写这篇博文，主要是因为最近的境遇导致的，关于本文的内容，也并非完全是我个人的感想，大部分是来自于网络上大家有的共同的疑问，我将它抽取出来，写在这里的，希望能够引起大家的思考，对大家有所帮助。

　　最后，感谢下被我摘取了内容的几个博客的作者，顺便附上他们的链接，大家也可以直接到他们的博客上看原文：

　　1.MeteorSeed ：http://www.cnblogs.com/MeteorSeed/archive/2012/03/21/2404656.html

　　2.Mark CC ：http://www.aqee.net/google-coding-standards/

　　3.永无止境，上下求索 ：http://blog.csdn.net/kimylrong/article/details/7700311