编码规范浅谈

原创
2013/09/11 16:35
阅读数 237

1、开篇问题

       1)代码是写给谁看的,机器还是人?

       2)半月前写的代码现在还可以看懂吗?那么,一年前、两年前的呢?

       3)刚进公司,是有没有出现没有编码规范而看不懂代码?相反,编码规范和自己的习惯产生冲突的纠结感呢? 

2、编码规范的必要性

       先来谈谈第一个问题。代码是人编出来的,它的最终读者是谁呢?其实,代码的读者也就两种,编译器和人。对于编译器,它只需要读一次,然后编译成机器可以执行的二进制数据,剩下的就没它什么事了。而对于人来说,不仅仅自己要读,项目的其他成员也需要阅读,接手你工作的代码维护人员也需要阅读;如果开源的话,可能会有很多人要读。

       如果你的代码没有一点规范,随便使用abc来命名变量,函数名一会大写一会小写,代码的布局乱七八糟,一个文件里写了很多类,每个函数都长的惊人,注释要么没有要么文不对题,相信没人愿意去看这样的代码。好不容易辛辛苦苦敲出来的代码,得不到大家的认可;过一段时间,自己也看不懂了,遇到维护,修改还不如重写呢! 

3、狭义编码规范

       刚开始接触编码规范时,总是认为编码规范就是一个公司制定的代码规范,公司里的所有团队都要遵循。我相信有公司是这样做的,不然也不会引起一些人对编码规范的反感。

       如果这个公司的编码规范与时俱进、不停完善,毋庸置疑这将是一个很好的决策,就算是新手花两三天时间熟悉一下规范手册,也可以直接融入团队,这样公司就不会担心人才的流失了。

但是,从很多人对此的反感,可以推测公司的编码规范都是几年前编写的,生搬硬套,不懂变通,比如非要使用Java的方式约束C#等。这样的编码规范已经没意义了,但还要沿袭下去。这样做也许是为了申请非物质文化遗产吧,别太纠结了。 

4、广义编码规范

之所以叫做广义,就是为了突破狭义的限制,取其精华去其糟粕。

我们可以把狭义进行拓展,比如拓展到团队,公司没有编码规范,而要求每个开发团队都要制定自己的编码规范。这样,团队的成员进行讨论,不停的改进,也就与时俱进了,由于团队规范会考虑到个人,所以团队规范会尽可能照顾到每一个人。

还可以再进行拓展,到个人或者结对编程中的对。这样可以看作是完全无限制的,自由开放的,但是这个时候需要每个人都要有自己的编码规范。这个时候的代码更像是一份信,让你的同事了解你的风格,进而了解你。

5、总结

       至于编码规范,仁者见仁,智者见智。

       在计算机内存、CPU、硬盘很稀有的情况下,人们不得已使用单字节来标识变量,数据也是能省则省,结果省出了千年虫。

       现在,计算机的发展已经在某种程度上可以忽略资源的限制;行业交流越来越通畅,大家交流的载体大多不是文档,而是代码。在这种情况下,大家应该是时候考虑编码规范了。

       至于怎么实施,建议:计划,个人实践,修改,团队实践,修改,公司推广,不断完善。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
2 收藏
0
分享
返回顶部
顶部