标签：
我对这四个问题均持反驳的看法，下面是我的理由~
其实很简单，因为统一编码规范可以造就代码风格的一致性。在团队里每个开发者所看到的代码，无论是自己写的或者是别人写的，都将有着统一的代码结构，有着一样的命名协定。这样的代码给人带来阅读源码愉悦的体验：你看别人的代码就像看你自己的代码一样！当然好的注释是非常必要的，否则别人的代码就算像是自己写的代码，一个月后估计就只有上帝能看懂了。
我以为这样做还有个好处就是“一次制定，终身受用”。比如开发某大型商用软件，如果开始能够统一代码规范，那么即使最初的开发者离职了，接手的新人也能够从统一的规范中快速入手并进行同样规范下的源码修改。通过遵循一致的风格，此种规范能够让其他开发人员的介入、帮助、维护或新的发展变得高效有序。而且代码规范具有极高的复用性，在不断的实践中总结出一套好的规范集，能够在许多大型软件开发前就做出约束与规定，这样对以后的每个软件开发流程都有非常好的影响。
并且，统一风格利于寻找bug。在做代码审查的过程中，规范一致的代码对于审查的效率提升有莫大帮助。想象一下你看这一堆你觉得像坨屎一样的代码进行code review的时候会有多好的心情吗...还会想着认真寻找bug吗？看都不想看，还能让人好好review嘛！
最后，我觉得是对于程序员个人的一种收获。编码规范的统一更利于程序员自身主人翁意识的培养，这种意识的培养我觉得是工程师与码农的很大区别之一（纯属个人意见）。能够对自己的代码负责，就能够开发出更加高质量的代码，对于工程师本身也是能力的锻炼。如果开发者从来不管代码后续的维护问题，不管源码的可阅读性问题，那么对他而言码代码只能算作是一种工作，而从来不能称之为艺术。
代码书写过程中所遵循的编码规范，有时就好像是一个作家在书里的写书风格。它们的共同之处当然有：它们往往容易被忽略，只有少数人才能够严格地遵循它们，并且这些人最后往往能够成功。但是它们当然也有着巨大的不同：作家写书是单兵作战，而工程推进大部分时候是团队合作的。
问题所述的情景在很多软件开发过程中都会很常见。许多程序员都以自己的编码风格为傲，有些甚至是为了代码而代码的。将本来逻辑清晰的代码写得复杂又难懂——这样或许能为他在部门经理心中的地位的提升做出很大贡献？或者只是为了装x(捂脸)？...只是调侃一下：D。复杂晦涩难懂的代码，或者说句法怪癖，基本不可读的代码，是很难得到他人的认同与维护的。能力与创造力和是否坚持自己的怪癖规范没有半毛钱关系。
当然传统软件工程开发里不乏很多单兵作战的例子，比如Ken Thompson、Linus Torvalds、还有Donald Ervin Knuth教授“排版不爽就做个Tex”的让人津津乐道的故事。确实，上个世纪涌现出的这些享誉世界的Hacker们，确实是以一己之力震惊世界的程序员的典范，是真正的程序员。
但是，他们是艺术家，然而我们现在并不是。艺术家往往是富有灵感与创意的，但是艺术家是有前提的：必须得有足够的天份与更多的练习。也就是说：首先你需要是个匠人，然后你才可能是个艺术家。
作为一名solo developer，渴望成为superhero而独立开发软件，在现代软件工程的复杂程度下，基本是不可行的。开发初期，我们可能会因为自己可以随意制定规范与原则而感到效率极高：不需要跟别人开发的模块耦合，不需要“被迫”写注释，不需要花“大量的时间”去改变自己原先的编码规范而适应团队的编码规范，不需要做大量“无用”的交流工作。
但是作为一名独立开发者最大的好处同时也可能是最大的坏处就在于两个字：自由。时间越长，对于独立的开发人员来说一个软件的发布就越困难。除非开发者本身本来就有详尽的知识技术、可行的解决方案和大量开发的经验。但是现实往往是残酷的，每个人都会有自己的思维盲点，在开发中这是避免不了的。我的观点不是说某个人不能开发一个小的软件，我的意思是说，一个人在付出足够多的努力成为“艺术家”之前，软件开发流程往往会因为设计的局限与解决方案的不准确而被迫停止。
而且，对于软件的开发流程的推进，除非开发者是一个非常自律的人，不然可能遇到某个大的bug开发者就会丧失后续开发与维护的想法了。但是如果是在一个团队中的话，大家可以一起想办法解决bug，至少不会让开发者丧失后续开发的信心。
所以说，每个开发者在想要一直保持“自己的规范与原则”前，需要认真地考虑一下自己是否真的是工程开发中的“艺术家”。如果还不是，那么就必须遵守团队的编码规范；如果是，等到成为“艺术家”的时候，开发者自己也应该明白团队编码规范一致的重要性了。
未完...
标签：
原文地址：http://www.cnblogs.com/SivilTaram/p/4847712.html
