一位IT碼農加入谷歌後，對編碼規範有了全新的認識：

在到谷歌工作之前，我一直認為編碼規範沒有什麼用處。我堅信這些規範都是官僚制度下產生的浪費大家的程式設計時間、影響人們開發效率的東西。

現在看來，我是大錯特錯了。

在谷歌，我可以檢視任何的程式碼，進入所有谷歌的程式碼庫，我有權檢視它們。事實上，這種許可權是很少人能擁有的。但是，讓我感到驚訝的卻是，如此多的編碼規範—縮排，命名，檔案結構，註釋風格—這一切讓我出乎意料的輕鬆的閱讀任意一段程式碼，並輕易的看懂它們。這讓我震驚—因為我以為這些規範是微不足道的東西。它們不可能有這麼大的作用—但它們卻起到了這麼大的作用。當你發現只通過看程式的基本語法結構就能讀懂一段程式碼，這種時間上的節省不能不讓人震撼！

反對編碼規範的人很多，下面是一些常見的理由，對於這些理由，我以前是深信不疑的：

這是浪費時間！
我是一個優秀的程式設計師，我不願意浪費時間幹這些愚蠢的事。我的技術很好，我可以寫出清晰的、易於理解的程式碼。為什麼我要浪費時間遵守這些愚蠢的規範？答案是：統一是有價值的。就像我前面說的—你看到的任何的一行程式碼—不論是由你寫的，還是由你身邊的同事，還是由一個跟你相差11個時區的距離人寫的—它們都有統一的結構，相同的命名規範—這帶來的效果是巨大的。你只需要花這麼少的功夫就能看懂一個你不熟悉(或完全未見過)的程式，因為你一見它們就會覺得面熟。

我是個藝術家！
這種話很滑稽，但它反映了一種常見的抱怨。我們程式設計師對於自己的編碼風格通常懷有很高的自負。我寫出的的程式碼的確能反映出我的一些特質，它是我思考的一種體現。它是我的技能和創造力的印證。如果你強迫我遵守什麼愚蠢的規範，這是在打壓我的創造力。可問題是，你的風格里的重要的部分，它對你的思想和創造力的體現，並不是藏身於這些微不足道的句法形式裡。(如果是的話，那麼，你是一個相當糟糕的程式設計師。)規範事實上可以讓人們可以更容易的看出你的創造力—因為他們看明白了你的作品，人們對你的認識不會因不熟悉的編碼形式而受到干擾。

不是每雙鞋都適合所有人！
如果你使用的編碼規範並不是為你的專案專門設計的，它對你的專案也許並不是最佳方案。這沒事。同樣，這只是語法：非最優並不表示是不好。對你的專案來說它不是最理想的，但並不能表明它不值得遵守。不錯，對於你的專案，你並沒有從中獲得該有的好處，但對於一個大型公司來說，它帶來的好處是巨大的。除此之外，專門針對某個專案制定編碼規範一般效果會更好。一個專案擁有自己的編碼風格無可厚非。但是，根據我的經驗，在一個大型公司裡，你最好有一個統一的編碼規範，特定專案可以擴充套件自己特定的專案方言和結構。

我擅長制定編碼規範！
這應該是最常見的抱怨型別了。它是其它幾種反對聲音的混合體，但它卻有自身態度的直接表現。有一部分反對者深信，他們是比制定編碼規範的人更好的程式設計師，俯身屈從這些小學生制定的規範，將會降低程式碼的質量。對於此，客氣點說，就是胡扯。純屬傲慢自大，荒唐可笑。事實上他們的意思就是，沒有人配得上給他們制定規範，對他們的程式碼的任何改動都是一種破壞。如果參照任何一種合理的編碼規範，你都不能寫出合格的程式碼，那隻能說你是個爛程式設計師。

當你按照某種編碼規範進行程式設計時，必然會有某些地方讓你搖頭不爽。肯定會在某些地方你的編碼風格會優於這些規範。但是，這不重要。在某些地方，編碼規範也有優於你的程式設計風格的時候。但是，這也不重要。只要這規範不是完全的不可理喻，在程式的可理解性上得到的好處會大大的補償你的損失。

但是，如果編碼規範真的是完全不可理喻呢？

如果是這樣，那就麻煩了：你被糟蹋了。但這並不是因為這荒謬的編碼規範。這是因為你在跟一群蠢貨一起工作。想通過把編碼規範制定的足夠荒謬來阻止一個優秀的程式設計師寫出優秀的程式碼，這需要努力。這需要一個執著的、冷靜的、進了水的大腦。如果這群蠢貨能強行頒佈不可用的編碼規範，那他們就能幹出其它很多傻事情。如果你為這群蠢貨幹活，你的確被糟蹋了—不論你幹什麼、有沒有規範。(我並不是說罕有公司被一群蠢貨管理；事實很不幸，我們這個世界從來就不缺蠢貨，而且很多蠢貨都擁有自己的公司。)

本文來自：外刊IT評論 ( http://scientopia.org/blogs/goodmath/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/ )