大家是否发现把时间浪费在讨论编码规范的分歧上，事后又觉得那些都是徒劳无功的事情。

每个人都希望有人赞赏他的编码风格。就像多年前的我一样，在那时（相对于今天来说），C语言还是那种拥有多个竞争风格的语言。这里有K&R风格，但从未引起我的兴趣并且当时还有其他需要编译的事情。有些人开发是基于一种美学的编码风格，还有的基于可读性或者其他方面的——采用堂吉诃德式的信仰来编写，if（4==y）的这种风格，可以提高代码的正确性。我个人的编码风格是从那个时候开始的，我拥有一个属于自己的C语言杂志，为了让代码尽可能清晰的打印在杂志上，所以我尽可能多留一些垂直空间并且在操作符号周围多使用一些空格。即使今天，代码打印出来后仍能清晰地阅读。Java代码编写风格也这样。C语言编码风格继承并稍作些调整，但至少对于我来说，打印效果还是非常棒。

在我工作过的许多网站都进行过长期地讨论，怎样才是最好的编码风格？我见过许多开发人员抱怨被迫采用一些规范，使他们的语法和语义被破坏。对于这些规范，甚至多年前，我的感觉就像是一个成年代码保姆。关于这种辩论的核心莫过于可选字符的使用、大括号位置、代码块如何缩进、空白空间的大小、注释格式以及语句声明等。鉴于如此丰富的细节，任何带有偏好的明智组合都不可能提供如此高的竞争性集合。这根本是不值得进行讨论的。

有一个比较重要的问题是，在一个不同理论风格的网站下面，开发人员允许使用彼此最舒服最擅长的编码风格，这样就会导致如下几个问题：首先，有些程序员的编码风格会很奇怪；其次在一个代码库里面可能有多种编码风格，代码很难读尤其当多个人去维护的时候；最后，在代码被维护或者更新的时候，许多开发人员会根据他们的喜好重组代码块。这些会使一些毫无意义的增量在代码里面生成，这样维护起来不仅仅浪费时间，而且会让代码越来越乱，反而增加维护成本。

采用单一的编码风格是网站最佳的解决方案。坚持统一的编码风格是至关重要的，但很少有两个网站或者公司的编码风格是一样的，所以当开发人员加入到新团队以后，还是会浪费一些时间。在我看来，最佳的解决方案是让语言设计者在设计时尽可能地多采用些风格，这种方法可以大大方便阅读和代码编写，语言设计者已经慢慢认识到它的好处。在早期的语言中，例如上面提到的C语言，但是Fortran却更加疯狂，它甚至在关键字后边都不需要留有空格，这使得各种各样的形式都涌现出来，并且还移交给那些不幸者维护了几十年。

不过在近期，语言已经加强了这方面的要求。Python对代码块有非常严格的缩进风格。谷歌的新兴系统语言Go，对括号的打开有了位置要求：在新行上，它们不可以成为第一个字符。某种意义上来说，Go语言的打开括号已经解决支持K&R这种编程风格。更重要地是，Python开发人员并没有对缩进有所抱怨，就像新兴Go程序员一样，对括号位置没有任何怨言。

这种可接受性表明，开发人员变得更加明智——承认风格一致性所带来的好处以及多样性所浪费的成本。追求这种主题，语言设计者将朝着这种方向走的更远。如今代码库已经越来越大——本周将完成1000万行代码，这绝对不是个非常大的数字——编译后拥有统一的代码风格并且强调可读性和删除那些“喋喋不休”的代码在很久以前就已经解决。作为一个单独的个体来说，我很愿意抛弃我已使用多年的编码风格来满足那些单一的、可读的、可委托方法的代码。