| description |
|---|
规范可以统一团队成员的编码习惯，使项目的编码风格保持一致性。 |
因为每个开发团队成员的水平都是参差不齐的，如果不制定好规范，每个人都自成体系，那团队间的合作就会变得困难，我看你的代码难受，你看我的代码也难受！就像缩紧是使用两个空格还是四个空格的问题，是没有标准答案的，大家都按照规范来。
按照规范编码最直接的结果就是项目结构和代码风格在视觉上带来的高度一致性，可读性等。当你去维护别人编写的代码时，至少看起来不会难受，对于有强迫症的程序员更是灾难！看下面google的风格指南。
上面的编码风格都没问题，笔者所在团队成员对每种风格都有支持者，这和个人审美有关，不能说谁对谁错。但是在一个项目中如果不统一风格就会造成你看我的代码难受，我看你的也难受，影响团队成员间的合作。
规范帮助我们编写更优雅和清晰的代码，没有规范的对输入输出参数的规范，没有规范的异常处理，没有规范的日志处理等等，不但导致了我们总是出现类似空指针这样低级的bug而且还很难找到引起bug的原因。相反，在规范的开发中，bug不但可以有效减少，查找bug也变得轻而易举。 规范不是对开发的制约，而确实是有助于提高开发效率的。
前期开发的代码质量，是直接影响后期的维护成本的，特别是后期维护人员已经不是当初开发人员的情况下，很大一部分时间都花在代码阅读和逻辑梳理上了（因代码没写注释，美一码农枪杀同事，码农也是高危行业啊！）。良好的编码习惯是一个程序员的自我修养，每个程序员都不希望自己辛辛苦苦编写的代码在经过A、B、C维护之后就变成了一座屎山吧，因为捋不清的代码逻辑经过后期维护只会越来越混乱（除非重构），直接导致的后果就是牵一发而动全身。
前面提到过，编码规范带来的好处就包括风格一致，可阅读性等，这些正是提高代码review效率的基础。如果自我陶醉的写了一大坨只有自己才能看的懂的代码（码神请忽略），那对review代码的同事来说就是一场灾难。按照规范编写风格统一的代码，看起来舒服，也能快速审查出不合理的地方。
规范不是技术而是一种约束和意识，编码不是技术而是一门艺术。特别是对于刚毕业的纯金人才，能在开始做项目时就能意识到编码规范的重要性，并按照规范编码，能更快的加速自身成长。
即使明白代码规范的好处，但是有的迫于项目压力，有的因为繁琐的规范作出很多额外的工作，更有的不重视维护的问题，而很难贯彻代码规范。但是我们需要明白，规范开发最大的受益人其实是自己！看一些大师级开源项目，程序编码都是极其规范的。并非规范了就代表高水平，实际上是规范的代码更有利于帮助你理解开发语言理解模式理解架构，能够帮助你快速提升开发水平。
项目中的规范包括很多方面，例如分支规范、编写风格规范、命名规范，代码注释等等。
分支管理在多人合作的项目中尤其显得重要，参考git 工作流-阮一峰老师。
看了谈谈编码风格与编码规范，里面说**“代码如人，风格的差异很正常，彼此尊重。相爱是灵魂的碰触，别停留在表象“，提倡每个人保持自己的编码风格，但是好看的皮囊千篇一律，有趣的灵魂万里挑一**。现实是并不是每个人都是大神，有些所谓的风格并不友好。如果我们查看第三方库源码发现每个文件都是一种编码风格，你会觉得很有趣吗？
命名规范包括文件夹、文件、类、组件、变量、方法名、函数名、样式类名以及其它资源名等等。
- 文件夹：连字符格式(my-test)或大写驼峰格式(MyTest)；
- 类名：大写驼峰格式(MyTest)；
- 组件名：连字符格式(my-test)或大写驼峰格式(MyTest)；
- 变量：小写开头驼峰格式（myTest）；
- 私有变量：下划线开头的驼峰格式(_myTest)；
命名不限于上述几种格式，但是格式一定要统一，不然你的组件名大写驼峰(MyTest)格式，我的组件名连字符(my-test)格式，虽不影响使用，但是一个项目中使用多种格式，影响阅读和。
发现编码了很多年的老工程师们也有很大一部分不喜欢写注释，注释不是喜不喜欢写的问题，而是必要的注释一定要写，比如核心的算法思想和实现思路以及一些复杂的业务逻辑。这些代码不写注释或技术文档那对于后来者，就需要花更多的时间去理解，特别是复杂业务逻辑，不写注释很容易牵一发而动全身，导致bug。而一些高喊“我看得懂就行“的老司机，肯定是认为代码不会有别人维护了吧！！！