认识达内从这里开始

对于程序员啦说，代码的规范化是需要慢慢培养的一种工作习惯。今天，我们就一起来了解一下，代码规范化对于我们的工作都有哪些影响。

代码规范的本身的

从规范目标细节的角度，代码规范分为：

注释

命名

缩进空格

语句格式

规模

可靠性

语言特殊项

代码规范从实施的角度，我分了几类：

简单易执行

命名、注释就是简单易执行

一般可执行

操作符++和— —操作符的应用是否符合规范?

只读不可写的常量加上readonly或者const

有难度自行掌控

一屏原则：一个方法体的代码幅应该在一屏比较和合理;逻辑复杂的代码可以抽离出方法体;

int的返回值是否合理?(负值为失败，非负值成功)

强迫症规范

很多关于空格类的规范，就属于强迫症规范

代码规范的养成，习惯比规范更重要

代码规范除了制定，其实更注重每个程序员的执行。程序员每天写代码的时候更规范，当然会比之后再review代码，再整理代码做的好的多。而写代码时的控制，更多的是一种习惯。代码规范前几条里必然有命名，缩进等，这些每天写代码的基本，必然是每个程序员的习惯，而不是时刻挂在脑子里，要想一下的东西。就像前端程序员写html的时候，一定会注意封闭性，写一个

一定成对出现。

代码规范的推行方式

IDE对于代码规范的影响，从侧面说明了另外一个，代码规范的推行。

我目前想到的代码规范的推行方式，定制工具，培养习惯，code review。

听说，百度以前学Google的时候，也搞了一套类似的模式。新程序员入职的时候，要先学习代码规范，然后学会整个编码发布的流程，其中就有自动化检查代码规范的流程，如果不通过，就回去继续改，不能发布。新程序员一般都要花上一两天学习这套东西，否则工作永远完成不了。这里说的就是代码规范的强制推行工具，帮助或者说限制程序员必须要按照制定的标准来。

学会使用统一的工具，统一开发环境或者IDE工具，使用统一的ESLint，JSLint配置。或者公司有统一的代码规范检查工具。

当然，有的规范可以工具化，有的不可以

例如大小写，下划线，每行长度，if后{}位置，空格的编写等。单个函数不超过规定行数?缩进层数是否不超过规定?这些很容易用工具来检查。

包装类做简单预算前是否保证非空? 建议都使用包装类。方法调用前是否有非空判断?这些就没这么容易了。而前面举例的一些自行掌控的规范，更是只能看程序员的素质了。

代码规范解决不了代码腐化的

一个长期在维护的代码，时间长了，难免出一些。例如需求的反复变化，导致的代码的杂乱，原先的需求是做一个贷款超市，过几天需求变了，变成了信用卡超市，过几天又变成了信用卡还款及记账工具，这些并不是代码规范就能解决的。根本的处理方法是重构，或者新代码的分割。

代码规范也会与时俱进

技术更新很快，工程过程中遇到的也是层出不穷，因此，代码规范也不会是一招定论的，需要不断地更新、补充、完善，这样才能与时俱进，保持生命力。举例说JAVA8中引入了Lambda表达式，对于半路出家的程序员，这种表达式如果写的抽象一些，可读性会出点的。有必要对于Lambda写法上做一定的规范。还有如C#和js中引入的await和async的异步写法，没学过直接看代码的时候，确实会发生不能理解的，说明还没有成熟规范写法，也没有深入学习语法的时候，新技术常常会导致可读性下降。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。