编码规范那些思考

一、问与答

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

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

 

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

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

 

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

  苦逼的我在这个星期阅读公司里面之前的项目代码的时候,全部都遇到过了。本身一个逻辑很简单的东西,我花的时间竟然比看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

posted @ 2013-08-18 14:45  小学徒V  阅读(2258)  评论(1编辑  收藏  举报