本文已在我的公众号「伯特说」原创首发。
我们经常调侃说：杀死一个程序员不用枪，改几次需求就行了。
没想到，国外真的发生了程序员枪击同事的事件。而原因，不是产品改需求，竟是同事写代码不规范：不写注释、不遵循驼峰命名、括号换行，最主要还天天 git push -f 提交代码。
枪击事件共导致 4 位同事不同程度受伤，其中两人伤情严重，一人情况危急。当事人在与警察的对峙中，被枪击中身亡。
当然，上述事件没有确切证实，或许是猜测，所以在这儿就不再细说了，不知情的可以去网上搜搜。
接下来，想与大家聊聊，这件事背后所凸显的编码规范的重要性。
1. 编码规范之于团队
多人协作的项目，如果大家编码毫无规范、风格迥异，毫无疑问，势必引发可读性差的问题，徒增后期维护成本，甚至无法维护。
另外，比较有意思的一点是，程序员大都有自己的个性：我写的代码是最标准的，你们写的都是 shit。
所以可想而知，风格迥异的代码，还会造成大家在日常工作中互相 diss，各种看不惯，长此以往势必影响团队协作及凝聚力。
2. 编码规范之于质量
很多人会问：质量取决于编码逻辑、算法，与规范何关？
殊不知，规范的代码不仅意味着风格统一、可读性高，在细节上还要求我们规范输入、输出，以及可能的异常处理等。
从可读性上来说，高可读使得在后期维护时，能有效避免因逻辑、业务不清晰造成的编码错误，从而提升产品质量。
从输入、输出及异常处理上来说，规范引发我们思考各种输入 case、边界条件等，以及正确处理异常情况而非崩溃，如有必要辅以相应的日志用于排查问题，从整体上提升代码的鲁棒性。
3. 编码规范之于个人
个人认为，规范对为所欲为的人来说，是一种约束；而对于具备良好编码习惯的人来说，是一种认可的标准。
其实，只要做到前面所说的，那么规范之于个人的意义就不言而喻了。最后，再补充一点：
如果不希望离职后，被接手你代码的人问候全家，那就从现在起规范编码。
如果你接手过别人的代码，你就知道这不是开玩笑。
我谨在此呼吁大家：请注重编码规范问题，不要“开发一时爽，维护火葬场”，况且现在看来真的有可能出人命。
最后，感谢这些年同事的不杀之恩，让我有机会写这篇文章，你们有机会读这篇文章。
欢迎关注我的公众号「伯特说」，在这里，读的越多，懂的越少。
