编码规范那些思考

1、问与答

做为软件开发者，咱们能够开发低等级的软件，但不能开发低质量的软件。

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

 

在网上，其实也有不少代码规范了，在官网上也有推荐的规范，但是为何咱们再这里还要这么麻烦制定一个属于本身的规范呢？

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

 

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

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

 

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

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

 

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

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

 

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

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

 2、概述

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

2.编码规范的好处

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

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

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

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

   5) 强调变量之间的关系，下降缺陷引人的机会 命名能够表示必定的逻辑关系，是开发人员在使用时保持警戒，从而必定程度上减小缺陷被引人的机会

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

3、感谢语

　　写这篇博文，主要是由于最近的境遇致使的，关于本文的内容，也并不是彻底是我我的的感想，大部分是来自于网络上你们有的共同的疑问，我将它抽取出来，写在这里的，但愿可以引发你们的思考，对你们有所帮助。

　　最后，感谢下被我摘取了内容的几个博客的做者，顺便附上他们的连接，你们也能够直接到他们的博客上看原文：

　　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