可能有同学觉得代码需要突出个人的特点,需要特异化,但是这样就会造成别人阅读起来很困难
代码不仅仅是交给机器来执行的,同时代码也是让其他同事来阅读的,如果代码不规范就会出现各种各样的问题,写多了代码只是觉得代码规范化是一件很自然的事,代码写多了,自然代码规范化咯,地球人都会。
其实不然,我们是不是缺少了小时候,十万个为什么的那种精神,为什么要这样做?为什么要那样做?那么我们为什么要做代码规范化?
下面程序员在修复 bug 时可能会说的一些话或者想法 ,你占了几条?赶紧一起来看看。
如果你忘记添加结束分号,只是一个无心的错误,但解析器不理解这一点,它会无情地抛出一个致命错误。然后,你必须再花 20 分钟来查看代码,最后你发现缺少了一个分号,也许这就是调试的“乐趣”。
但对于复杂一些的脚本和程序,就需要某种类型的注释,以便你在几个月后甚至几年后回过头来查看。
有时候你会忘记给函数及其参数、输出格式和其他基本数据添加注释,当出现错误时,你需要调试整个脚本才能找到解决方案时,这无疑会给你添乱,这个时候你就会想,如果当初加一些有用的注释就好了
听起来就像是一种妄想症,但有时你不得不怀疑,正当你忙着补觉时,是谁在写了这些代码
过去几周或几个月忙的项目让你感到沮丧,有时候你会不记得自己往代码库里添加过东西——甚至是上周刚刚查看过的项目!
你一股脑儿写了一个函数,然后函数输出了一个致命的错误
为了找到问题所在,你不得不把其他代码删掉,只留下出问题的那几行代码,当你最终找到问题并把它修复,你会感到筋疲力尽,但同时也松了一口气。
美观,排着整整齐齐的一行一行,看着就舒服;
要是不使用代码编写规范,每个方法的实现写一遍,相同的函数也不合并,在做重复的事情就是浪费时间的一件事情,而且在修改上也照成一定的困难,所以对于变量、类、接口、事件等都要有一定的规范;
如果是团队开发的话,没有规范更为混乱,要不就你有你的方法,我有我的接口,一个人来一套,那就真的乱套了,写有好味道的代码,我相信是每一个程序员的乐趣。
条理清晰,对于整个的项目,我们也需要一定的规范,项目多了,是采用三层、四层还是n层架构,对于开发的分工、项目的扩展性有很大的帮助,并且使用各种的设计模式,使得代码设计更加合理。
表以及视图的命名需要规范,不要将业务写进存储过程或者函数里面,我们应该都遇到过,一个SQL几千行的代码,修改阅读起来非常的痛苦。
编写文档,比较相当枯燥一点,但是对于整个开发的指引也相对重要,要整个团队都要看明白你写的东西,当然也是需要规范化的,如果文档编写的符合规范并且清晰明了,对于后面交接或者问题问题排查都是大有好处的。
编码规范对程序员非常重要的若干原因
几乎每个项目,每家公司都会定义自己的编码规范,但在真正实施时,却在有意或无意地违背编码规范
程序员不喜欢改变自己的编程习惯,加之,管理者对质量控制不足,导致编码规范往往形同虚设。
有些人会认为:遵守编码规范不能给项目带来利益,也不能让客户看到我们为此付出的努力,其完全是团队自发的行为,没有必要做硬性的要求。
还有些人有更好的理由:编码规范会破坏创造性和程序质量
编码规范,在软件构件以及项目管理中,甚至是个人成长方面,都发挥着重要的作用,好的编码规范是提高我们代码质量的最有效的工具之一
一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异。
且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了。
大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情,统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉,显然的,规范的代码在团队的合作开发中是非常有益而且必要的。
很多IT人士将程序员比做民工,这也的确非常的形象,就像刚才提到的,复杂的算法或逻辑只占项目中很小的比例,大多仅仅是垒代码的工作。
可是越是简单,测试的bug反而是越多,而且是无穷无尽的bug,这里很大的程度上是由于代码不规范所致。 没有规范的对输入输出参数的规范,没有规范的异常处理,没有规范的日志处理等等,不但导致了我们总是出现类似空指针这样低级的bug而且还很难找到引起bug的原因,相反,在规范的开发中,bug不但可以有效减少,查找bug也变得轻而易举, 规范不是对开发的制约,而确实是有助于提高开发效率的。
随着我们项目经验的累积,会越来越重视后期维护的成本,而开发过程中的代码质量直接影响着维护的成本,因此,我们不得不从开发时便小心翼翼。
在第一点中曾提到,规范的代码大大提高了程序的可读性,几乎所有的程序员都曾做过维护的工作,不用多说,可读性高的代码维护成本必然会大大降低。
但是,维护工作不仅仅是读懂原有代码,而是需要在原有代码基础上作出修改,我们可以先想像没有统一风格的情况下,A完成开发以后,B进行维护加一段代码,过一段时间C又加一段代码。。。。。。直到有一天X看到那一大堆乱码想死的心都有了,维护也就进行不下去了。
因此,统一的风格有利于长期的维护,另外,好的代码规范会对方法的度量、类的度量以及程序耦合性作出约束,这样不会出现需要修改一个上千行的方法或者去扩展一个没有接口的类的情况,规范的代码对程序的扩展性提高,无疑也是对维护人员的一个奖励。
一些公司里面会定期进行代码审查的,这样可以及时纠正一些错误,而且可以对开发人员的代码规范作出监督
团队的代码审查同时也是一个很好的学习机会,对成员的进步也是很有益的,但是,开发随意,加重的代码审查的工作量及难度,并且使得代码审查工作没有根据,浪费了大量的时间却收效甚微,代码规范不仅使得开发统一,减少审查监督,而且让代码审查有据可查,大大提高了审查效率和效果,同时代码审查也有助于代码规范的实施,一举多得,何乐而不为呢。
有助于程序员自身的成长 即使明白代码规范的好处,但是有的迫于项目压力,有的因为繁琐的规范作出很多额外的工作,更有的不重视维护的问题,而很难贯彻代码规范。
那么,我们需要了解,规范开发最大的受益人其实是自己!你有没有花费很多的时候查找自己的代码呢?尤其是出现bug的时候需要逐行的debug?自己写的代码乱了头绪的确实也见了不少,我们应该做的就是规范开发,减少自己出现的错误,很多时候项目的压力一部分也是由于前期开发中遗留的众多的问题。
还有的人觉得自己可以完成高难度的算法,就认为自己能力很强,不把规范放在眼里,很多人确实是这样,追求个性,大概让别人看他的代码一头雾水更觉得得意,殊不知复杂的算法确实可以体现你个人的逻辑能力,但是绝不代表你的开发水平,我们知道一些开源项目,一些大师级人物写得程序都是极其规范的,并非规范了就代表高水平,实际上是规范的代码更有利于帮助你理解开发语言理解模式理解架构,能够帮助你快速提升开发水平,不明白这点,即使你写的再高明的算法,没准哪天也被当作乱码别处理掉。
如果代码不规范写的时间长了,在写规范的代码是很痛苦的,并且我们不清楚什么样的代码是规范的(每个公司的规范不一样),可能到一个公司就需要新学习一套规范
我们可用借助一些权威的规范文档以及借助一些权威的工具让我们的代码更加规范,按照这些权威的文档或者工具的规范写出来的代码规范也是其他人能够认同的,下面我们介绍一些文档或者工具
业界公认的代码规范手册(国内)当属阿里巴巴旗下出版的《Java 开发手册》,经过几个版本的迭代,最新手册为《Java开发手册(黄山版)》,更新时间为2022年2月3号
手册以 Java 开发者为中心视角,划分为编程规约、异常日志、 单元测试、 安全规约、 MySQL 数据库、 工程结构、 设计规约七个维度,再根据内容特征,细分成若干二级子目录,根据约束力强弱及故障敏感性,规约依次分为强制、推荐、参考三大类。对于规约条目的延伸信息中,“说明” 对规约做了适当扩展和解释;“正例” 提倡什么样的编码和实现方式;“反例”说明需要提防的雷区, 以及真实的错误案例。
在软件研发过程中,bug越早发现,成本越低
代码扫描和单元测试,就是在早期帮我们发现程序中问题的有效手段,代码扫描不仅能帮我们发现程序的漏洞,也能督促开发人员更规范优雅地写代码。
但是如何培养好的代码规范呢,刚开始是可能对于很多代码规范不太了解,就可以采用一些代码规范工具帮助我们更好的培养好的代码规范,比如《阿里巴巴java开发手册》,sonar等代码质量管理平台等。
为了让开发者更加方便、快速将规范推动并实行起来,阿里巴巴基于手册内容,研发了一套自动化的IDE检测插件,于是在云栖大会上,发布了阿里人经过247天持续研发的阿里巴巴JAVA规约扫描插件——Alibaba Java Coding Guidelines.
该插件就是《阿里巴巴Java开发规约》的扩展,为了方便开发者,该插件作为一个IDE的插件形式,支持 IDEA 和Eclipse,当然也支持Android Studio( Android Studio是基于IDEA的)。
sonar是一款静态代码质量分析工具,支持Java、Python、PHP、JavaScript、CSS等25种以上的语言,而且能够集成在IDE、Jenkins、Git等服务中,方便随时查看代码质量分析报告。
Alibaba代码规范插件:比较关心的是代码规范,编码风格上的,例如,命名规范,注释,代码行数等。
SonarLint:比较关心代码正确性,存在的问题,风险,漏洞等,例如,重复代码,空指针,安全漏洞等。
所以,一般建议结合使用,使用前者来规范代码,使用后者来提前发现代码的问题,配合起来提高工程整体的代码质量,并且能够在编码阶段规避风险,提高程序的健壮性。