本文没有实际的代码规范，只是作为一个过来人，谈谈代码规范的重要性，也当算是记录一下自己一点小小的感悟吧。
如果问我怎么样算一个优秀的运动员？我的答案是在遵守比赛规则的约束下，取得好成绩的运动员。想想，如果一场比赛没有任何规则或者运动员都被红牌罚下场，这场比赛还具有什么意义吗？
在程序员行业，我们形容一个人优秀，我们不说优秀，我们称“大神”。在我看来一个程序员是不是大神，并不是在于他参与了多少个重大项目，写了多少代码或者是头顶凸不凸。而是他写的代码是否满足需求，足够优化，并且符合约定的代码规范。
现在的软件项目早已不是一个人的所能独立完成的了，最简单的一个企业项目，也得是团队协作才能完成，哪怕仅仅是一个端也是如此。而我们都知道，人人生而不同，每个人都是独特的，而大神们更有自己编码style。但如果每个人在项目里都按照自己的习惯和编码风格写代码，天马行空，不受任何约束。那么无论对于企业、团队、产品还是个人都简直是灾难。
代码规范是一种永恒的殇，一方面是因为它不是一个硬性规定，不像公司其他规章制度那样能强制所有人都遵守。如果公司领导不重视，团队经理不整理，我们甚至都会惊讶地听到，这家公司，这个团队可能都没有代码规范。另一方面是很多时候它没有对错。只要你的代码实现功能，完成需求，没人敢说你这么实现是错的，同级的同事在看到你的不规范代码的时候，撑死了只能在心里抱怨几句你写的垃圾代码。
本人做前端开发也差不多5年了，从小白慢慢成长过来，也是感受颇多。从一开始总以为，软件嘛，系统嘛肯定是代码最重要。接到需求二话不说，不闻不问就码代码，直到后面要求产品经理立字据不改需求。我才学会，代码不是最重要的，明确需求才重要。从一开始总以为，现在前后端开发分离了嘛，哪需要对啥对口，需求不摆着了吗？我这么调接口，后端接口这么给，不就完美了嘛。结果就是联调的各种扯皮，各种编译报错教会了我，还没对接口呢，写啥写，先对接口。从一开始总以为，大家都是做前端的嘛，我写我的模块，你写的你的模块，咱们都是按照原型需求来的嘛，功能实现，需求不减，不就好了嘛。直到合并代码或同事离职，我含着泪加班改着他的代码的时候，心里十万只羊驼奔腾而过，默念着“改你的代码，我还不如自己写”。我才逐渐明白，代码规范的重要性。代码规范，它是水，它是光，它是程序员不可或缺的东西。
先说说代码规范对于企业来说的重要性。一个好的公司好的企业必定有自己的内部一套规章制度和管理秩序。对于企业来说无规矩不成方圆，好的公司管理靠制度、靠流程。而对于一家科技公司来说，代码规范也应该属于公司规章制度的一部分。
衡量一家公司技术水平，代码规范也是一个重要参考标准。就拿阿里巴巴出的《阿里巴巴Java开发手册》来说，为什么这份开发手册能在java程序员之间广为流传。一是阿里巴巴企业的技术实力让很多人认可了这份规范，程序员在争执的时候往往会说“你看，阿里的就是这么写的”。二是确确实实这份代码规范在程序员日常工作中带来了巨大的益处。而从一份好的java规范，我们也能窥见阿里巴巴的技术水平。至少对于java代码规范来说，程序员认可了阿里。这个看似平常的操作，其实也是阿里的隐形资产。想想看，抛开企业排名等其他选择因素不说，如果一个java技术大牛选择跳槽，同样是一家不了解的大公司，另一家是用过这家规范的大公司，他会选择谁。
新入职的小伙伴很多时候会有感受，如果去一家公司，上来并不会让你马上写代码，而是先让你看几天的项目规范，代码规范，编码注意事项。你就会觉得这家公司很正规，做事有条理，流程很规范，从心里也会认可这家公司。而相反如果去一家小公司，上来就让你码代码，然后你看到别人之前的代码，一处一个样，别说风格统一，变量命名都是a、b、c，然后自己写得好坏，技术有没有提升，只有自己知道，那你心里肯定会对这家公司有芥蒂，对这家公司的技术实力也有所怀疑。我想这也是企业之间的一个差距吧。
再来说说代码规范对于团队的重要性。现在的我们无法否认，企业的软件开发肯定是一个团队合作的产物。运营上线的软件产品，在它的生命周期里，肯定是一直迭代更新的，在这期间整个技术团队也在进行技术积累，技术提升。
要想让团队形成技术积累，不会出现技术断层，那么团队技术的积累就应该保留在团队里形成团队产物，内化为团队资产，而不是绑定在某一个技术大牛身上。我们经常能够听到，某一个团队在某一个大牛离职了之后，团队的很多核心技术都在大牛的脑子一并被带走了。然后新成员接手项目就是一脸懵，没有人指导，没有技术文档，没有代码规范，一切都跟重新开始一样，整个团队技术水平就蹭蹭往下掉，干了几年的项目，项目成员一换，技术积累就回到解放前。
项目团队只有在项目开发、技术迭代过程中，有意识逐步地形成技术文档、技术手册、代码规范。并将这些东西通过培训、老带新等方式内化成每一个团队成员自身的技术内涵和实力，这样子才能整体提升项目团队技术水平，让团队技术水平与技术大牛解绑，不会因为技术大牛的离开而有太大影响。
代码规范能够保证项目代码库整体质量不会随着时间的推移而下降。因为代码库整体质量常常会随着每次提交代码质量的小幅下降而退化。如果在维护团队代码库时没有形成代码规范，今天这个小伙伴提交一点小问题，明天那个小伙伴提交一点小问题，哪怕就是0.01%的小问题，那么日积月累，对于代码库的质量就会形成负指数降低，直到无法挽回。难道我们希望直到后面代码库无法再进行维护了，那时再无奈地称之为“代码重构”？
从项目管理的角度来说，当项目刚进入编码周期时，代码规范可以不完善、不完美，一开始不应该追求完美，但是一定要有代码规范，并严格约束小伙伴的代码习惯，才不会为后面项目代码库埋坑。同时也应该追求代码规范持续改进，每一点改进都可以减少项目潜在风险，提高代码的性能和安全性。
需要认识到一点就是凡是能够成为代码规范的写法和实现方法，肯定是经过同行业无数程序员千锤百炼，共同认可的写法。虽然代码规范很多时候并不涉及业务逻辑的代码，但是一些语言特有的写法和实现方式，在形成规范之后能够解决命名冲突、关键字冲突等问题，对于团队项目来说也能很大程度避免bug的产生。
代码规范还有助于团队和谐，每一个程序员都不想在合并别人的代码之后自己的编辑器出现一大堆令人糟心的黄色波浪线或者红色警告线。当项目的一个端需要2个人以上进行共同开发时，没有代码规范无论对团队还是个人来说都是灾难。对于项目成员来说，当一个小伙伴合并代码之后出现了一大堆警告，生气地骂出“这TM谁写的代码”。这时无论对于谁，都是莫大的伤害。而当大家都遵循共同代码规范，在一个小伙伴在合并另一个小伙伴的代码之后，没有黄线，没有红线，编译通过，顺利提交，然后饱含深情地对着旁边的小伙伴说一句“写的不错”，这样子的一个风景难道不是更靓丽吗？
我们都认同好的项目是管出来的，同样好的代码也是管出来的。要想管好代码，那就得有规范。代码规范这东西，对于团队而言，肯定是百利而无一害的。对于一份团队里的代码规范，我们不奢求一开始就尽善尽美，而是应该持续持续迭代，持续更新。一个好的技术团队或项目，不仅仅产生设计文档、代码、上线产品，也应该产出更加规范的代码规范，让代码规范也成为团队技术实力和产品的一部分。
最后代码规范对个人而言，重要性也是不言而喻的。冰冻三尺，非一日之寒，没有人会天生写代码，技术大牛都是小白成长而来的。“道路千万条，规范第一条”，对自己有约束有自控力，才能让自己更好地成长。你会发现，技术大牛都会有自己的编码style，而且很多时候这些style会让你觉得很专业，很权威，心里也对大牛多了几分敬意，自己有了成长的目标，也知道了该如何成为一名技术大牛。
举一反三，代码规范会让你理解其他更多的东西。有时候人就是这样，不经历过那种痛苦，永远不会理解别人的苦口婆心。我相信，当你经历几次熬夜加班改bug，而且每次都不是因为你的功能没有实现，也不是产品经理的需求没有完成，而是你合并了别人的代码死活找不出bug，编译报错，commit不了，push不上。最后发现这个bug是因为代码不规范导致的时候，你就会明白为什么会有发明eslint的那个人，为什么代码要加无关乎功能实现、性能优化的代码校验，为什么你的项目组长要设置层层关卡不让你轻易提交代码。
我们都知道自己现在写的代码，都是给未来的自己看的。让自己在以后能够骂自己一句，“wc，我之前写的什么狗屁玩意”那么恭喜你，你已经成为一个自律的人了，甚至已经有了自己的编码style。这时即便没有代码规范，哪怕只有你一个人写一个项目的时候，你也能保证整个项目风格统一了。这时候，你会惊讶于如果一个团队项目，如果没有代码规范，那么是多么不可思议的一个事情。
作为一个程序员，当你的小伙伴对你说“你真个是天才，代码回路这么清奇，我都看不懂”，请你注意，这并不是在夸你。想想如果因为别人代码不规范，你得含泪加班改代码的时候。你有为你掉过的头发想过吗？它们是那么地无辜。所以，为了让自己少掉头发，也为了别人少掉头发，请务必遵循代码规范。毕竟，改别人的代码真的比自己写痛苦多了。
最后希望在有代码规范约束每一个程序员，都能写出优美、规范的代码，身经百战，成为自己钦佩的大牛。
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。——佚名
