谈起代码质量，可读性，可维护性等，总是说，我们要有一套代码规范来严格执行。我经历的公司，大多都有代码规范，至于最终代码规范有没有发挥作用么，你猜……
代码规范从制定到实施到发挥作用，其实还是有很多小的细节，今天我就来说说我看到的一些细节。
代码规范的本身的问题
从规范目标细节的角度，代码规范分为：
- 注释
- 命名
- 缩进空格
- 语句格式
- 规模
- 可靠性
- 语言特殊项
代码规范从实施的角度，我分了几类：
- 简单易执行
命名、注释就是简单易执行
- 一般可执行
操作符＋＋和— —操作符的应用是否符合规范？
只读不可写的常量加上readonly或者const
- 有难度自行掌控
一屏原则：一个方法体的代码幅应该在一屏比较和合理；逻辑复杂的代码可以抽离出方法体；
int的返回值是否合理？（负值为失败，非负值成功）
- 强迫症规范
很多关于空格类的规范，就属于强迫症规范
@Class的写法
写法模板：@class class1, class2;
建议的写法
1
|
@class UIView, UIImage;
|
不建议的写法
1
|
@class UIPress;
|
以上的规范，纯属编写规范的人的个人喜好，写法上我觉得没有对错，有一些过线。
5.关于特定语言或者数据库的编码特殊限定需求
例如：进行equal判断时，倒着写的规范：
if(“true”.equals(isLogin)){return true;}
用StringBuffer代替String；用Stringbulider代替StringBuffer；
网上我还是看了不少的规范，真的好的规范不多。代码规范一般会由团队里资深的程序员来制定，制定的方法一般是网上找一个基本的Base版，再做增减。专业的事交给专业的人来做，代码规范的制定应该由在一线摸爬滚打很多年的程序员主导，由多人参与共同制定，牵头人最好是做过很多大项目，有多年编程经验，为人谦虚，并一直保持学习状态的全栈工程师。
一个好的代码规范，必须由所有的团队成员一起认同，共同来维护，而不是由制定的人，来负责推广监督执行。在一开始制定的时候，就要充分的听取各方的意见，达成一致。有的代码规范太细，在写代码的时候，没法细抠，在事后也没有机会review，与其不能执行，不如简化些，更接地气。有的代码规范太抽象，例如函数规模，代码规模等，还是要有可量化标准，可执行的方法，最好能有工具支持，例如写代码时的提示，编译代码前的格式自动检查等等。
代码规范的养成，习惯比规范更重要
代码规范除了制定，其实更注重每个程序员的执行。程序员每天写代码的时候更规范，当然会比之后再review代码，再整理代码做的好的多。而写代码时的控制，更多的是一种习惯。代码规范前几条里必然有命名，缩进等，这些每天写代码的基本，必然是每个程序员的习惯，而不是时刻挂在脑子里，要想一下的东西。就像前端程序员写html的时候，一定会注意封闭性，写一个<div></div>一定成对出现。
对于刚开始写代码的小白来说，只要写一段时间的代码，习惯也会慢慢养成。这种养成是IDE协助下的养成。或者说，养成了IDE建议我们的习惯。举例说，JAVA的eclipse协助生成get;set;的代码，默认的会有setApplicationId这样的大小写习惯，会有{在前一行最后的默认习惯
1
|
for(int i=0;i<max;i++){
|
而同样的，C#的著名IDE Visual Studio就会帮.Net程序员养成，{}分行的习惯（默认配置是这样的）
1
|
for(int i=0;i<max;i++)
|
渐渐的，IDE帮我们区分了这个程序员是写什么代码出身的，给程序员的代码打上了不同种类的标准印记。有些左撇子在小时候，父母会强制他们用右手拿筷子吃饭，IDE的这种强制，对之后程序员的制定代码规范也有深深的印记。他们会觉得，自己最熟悉的那种类型，那种习惯就是正确的。我看了很多语言的代码规范后，发现这种IDE的习惯的影响力还真的是很强，也会影响到代码规范的制定。
另一方面，有的习惯是工具帮不了我们的。例如代码规模的控制，例如有野生程序员喜欢用拼音来命名。一些优秀程序员需要养成的习惯：
- 用合理命名的习惯
- 定期整理代码的习惯->清理无用代码->分割大段代码为更小的函数
- 注释的习惯
- 写文档的习惯
当然好的习惯远远不止以上这些，好习惯就是每个程序员的功底，内功，基础越好的程序员，写代码的效率当然越高。
代码规范的推行方式
IDE对于代码规范的影响，从侧面说明了另外一个问题，代码规范的推行问题。
我目前想到的代码规范的推行方式，定制工具，培养习惯，code review。
听说，百度以前学Google的时候，也搞了一套类似的模式。新程序员入职的时候，要先学习代码规范，然后学会整个编码发布的流程，其中就有自动化检查代码规范的流程，如果不通过，就回去继续改，不能发布。新程序员一般都要花上一两天学习这套东西，否则工作永远完成不了。这里说的就是代码规范的强制推行工具，帮助或者说限制程序员必须要按照制定的标准来。
学会使用统一的工具，统一开发环境或者IDE工具，使用统一的ESLint，JSLint配置。或者公司有统一的代码规范检查工具。
当然，有的规范可以工具化，有的不可以
例如大小写问题，下划线问题，每行长度问题，if后{}位置问题，空格的编写等。单个函数不超过规定行数？缩进层数是否不超过规定？这些很容易用工具来检查。
包装类做简单预算前是否保证非空？ 建议都使用包装类。方法调用前是否有非空判断？这些就没这么容易了。而前面举例的一些自行掌控的规范，更是只能看程序员的素质了。
代码规范推行的最后一招，就是code review。具体分实时review，编写后review，meeting review。 实时是指结对编程的那种方式，编写后是说Leader帮忙检查代码，meeting review的代价最大，一组人一起审阅代码。
代码规范为什么难以推行？因为没有自动化。规范的条条框框这么多，随时记在脑子里，怎么可能？不要指望程序员手工写代码的时候，能认真执行这些规则。从推行方式来看，IDE工具或者统一配置IDE工具的方式最简单->定制代码检查和规范工具->培养程序员习惯->code review。而现实情况见的最多的执行方案，是先安排个人制定一套规范，用代价最高的code review的方式来推行，几次之后，大家都觉得性价比低而放弃了。一个好的代码规范的推行，要更多的自动化，更早的在编写过程中处理问题。
代码规范的其他
-
代码规范不应该做的事情
太细节的东西不要管，假设我告诉你每天出门先迈右脚会走好运，每天你能做的到吗？例如，有看到过下面的规范要求，除
非IDE工具可以自动帮我做到这些，我个人就觉得，管的有些太细。
属于个人习惯的东西，不要强加在别人身上。但同一份代码，多个人编写，尽量参照之前的风格。别让后人看一份代码的时候产生混乱的感觉。1
2
3
4
5一般写法
app_name="支付宝";
规范要求，为了可读性，前后需要加入空格
app_name = "支付宝"; -
代码规范解决不了代码腐化的问题
一个长期在维护的代码，时间长了，难免出一些问题。例如需求的反复变化，导致的代码的杂乱，原先的需求是做一个贷款超市，过几天需求变了，变成了信用卡超市，过几天又变成了信用卡还款及记账工具，这些并不是代码规范就能解决的。根本的处理方法是重构，或者新代码的分割。
- 代码规范也会与时俱进
技术更新很快，工程过程中遇到的问题也是层出不穷，因此，代码规范也不会是一招定论的，需要不断地更新、补充、完善，这样才能与时俱进，保持生命力。举例说JAVA8中引入了Lambda表达式，对于半路出家的程序员，这种表达式如果写的抽象一些，可读性会出点问题的。有必要对于Lambda写法上做一定的规范。还有如C#和js中引入的await和async的异步写法，没学过直接看代码的时候，确实会发生不能理解的问题，说明还没有成熟规范写法，也没有深入学习语法的时候，新技术常常会导致可读性下降。
小结
一个技术团队的气质的重要表现就是团队的代码规范。一个阿里出来的程序员，之后写出来的代码，必然也会有之前的习惯，因为都是受过同一个代码规范熏陶的，这就是团队气质的体现，每当看到小公司混乱代码的时候，就会想大厂和小厂的不同。如果团队的开发都带有相同的气质，这个团队的统一性，战斗力就会是惊人的，外人看来，这就是团队而不是写代码的个体了。代码规范及其执行对于技术团队十分的重要，制定好代码规范，推行好代码规范，持续的优化，会让团队的效率大大的提升，是每一个技术团队Leader的重要抓手。
附件
什么样的代码规范才能得到程序员的认可？
http://www.cocoachina.com/programmer/20180327/22782.html
关于代码规范的一些参考
https://blog.csdn.net/mengdonghui123456/article/details/68066766
这可能是史上最全的Android代码规范
https://www.jianshu.com/p/f5a55dff62f0
阿里巴巴java代码规范
https://github.com/alibaba/p3c/blob/master/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4Java%E5%BC%80%E5%8F%91%E6%89%8B%E5%86%8C%EF%BC%88%E8%AF%A6%E5%B0%BD%E7%89%88%EF%BC%89.pdf