在Google，我们做的另一件事——严格的编码规范——让我感到出乎意料地有效、有用。
在进入Google之前，我一直认定编码规范毫无意义。我丝毫不怀疑，这类东西不过是一群斤斤计较的官僚闲着没事干弄出来、专门用来刁难真正干活的人的玩意儿。
事实证明，我大错特错。
在Google，我可以查看代码库里任何地方的任何一段代码，而且能看懂它。能被允许这样做，这件事本身就已经很不寻常了。但真正让我意外的是，风格上的标准化——缩进、命名、文件结构、注释规范——竟然能让人在阅读一段陌生代码时轻松这么多。直到现在，这一点仍然让我感到意外，因为这些说到底都是些微不足道的小事。按理说它们不该有多大影响——但事实上影响很大。你会惊讶地发现，读代码花掉的大部分时间，其实都耗在辨认最基本的语法结构上！
针对这一点，有一整套常见的反对意见，而这些意见我以前也都深信不疑。
这是在浪费时间！
我是个优秀的程序员，我不想把时间浪费在蠢事上。我水平够高，写出来的代码本身就清晰易懂。为什么要把时间浪费在什么破规范上？答案是：因为统一性本身就有价值。就像我前面提到的——不管你看的这段代码是你自己写的、是你最要好的同事写的，还是相隔11个时区之外某个陌生人写的，只要它们始终以同样的方式划分结构、始终使用同样的命名约定——这真的、切实地会带来巨大差别。面对那些你很久没看过（甚至从没看过）的代码，你需要付出的精力会少得多，因为你能立刻辨认出其中的结构。
我是个艺术家！
这话说得有点调侃，但它确实反映了一种常见的抱怨。我们程序员对自己的个人风格是很自豪的。我写的代码，确实能反映出关于我、关于我思维方式的一些东西，是我的技艺和创造力的体现。如果被迫套用某种死板的规范，感觉就像是在扼杀我的创造力。但问题是，你风格里真正重要的部分——真正体现你思维和创造力的部分——根本不在那些琐碎的语法细节上（如果是的话，那你这个程序员当得也太差劲了）。规范其实反而能让别人更容易看到你的创造力——因为他们能真正看清你在做什么，而不会被那些陌生的语法怪癖分散注意力。
一刀切等于谁都不合适！
如果你用的编码规范不是专门为你的项目设计的，那它对你的项目来说，很可能就不是最优的。这没关系。再说一遍，这只是语法层面的东西：不是最优，不等于不好。对你的项目来说不理想，不代表这件事就不值得做。没错，这确实会削减它给你项目带来的那部分好处，但与此同时，它也放大了整个组织能获得的好处。此外，为特定项目量身定制专属的代码风格，往往也是合情合理的，这完全没问题。事实上，根据我的经验，最好的做法是：整个组织有一套非常通用的编码规范，然后各个项目再针对自己特有的习惯用法和结构，在这个基础上做出扩展。 我水平太高，用不着这个！
这其实是最常见的一种反对意见。它算是前面几种的某种综合，但它更直接地暴露出一种潜在的态度：抱怨者内心认定，自己比制定规范的人更会写代码，如果屈就于一个由"不如自己"的人写出来的规范，只会拉低代码质量。说得客气点，这纯属胡扯。这是纯粹的傲慢，而且很荒谬。事实是，没有谁厉害到能让编码风格上的任何改动都损害代码质量。如果换了随便一套合理的编码规范你就写不出好代码，那你就是个蹩脚的程序员。
当你按照某种规范写代码时，难免会遇到一些你不认同这个规范的地方——有些地方，你的个人风格确实比规范更好。但这不重要。同样，大概率也会有一些地方，规范比你的风格更好，但这同样不重要。只要这个规范没有荒谬到家，它带来的可读性收益，就足以远远抵消这些代价。
但如果编码规范本身就荒谬到家了呢？
那好吧，那算你倒霉：你完蛋了。但这其实不是因为这套荒谬的编码规范，而是因为你在为一群蠢货打工。要把一套编码规范搞砸到真能阻止优秀程序员写出好代码的地步，其实很难——这需要一种执着的、冥顽不灵的愚蠢才做得到。如果你的老板蠢到会强推一套烂透了的编码规范，那他们大概率在别的方面也蠢事不断。如果你在为蠢货打工，那不管有没有编码规范，你基本上都已经完蛋了。（我并不是说由蠢货经营的软件公司很罕见——很不幸，这是个事实：蠢货从来不缺，而且不少还自己开公司当上了老板。）