這四個問題均是出自 http://goodmath.scientopia.org/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/ 。
我對這四個問題均持反駁的看法，下面是我的理由~
Q1：這些規範都是官僚制度下産生的浪費大家的程式設計時間、影響人們開發效率, 浪費時間的東西。
A1：
其實很簡單，因為統一編碼規範可以造就代碼風格的一緻性。在團隊裡每個開發者所看到的代碼，無論是自己寫的或者是别人寫的，都将有着統一的代碼結構，有着一樣的命名協定。這樣的代碼給人帶來閱讀源碼愉悅的體驗：你看别人的代碼就像看你自己的代碼一樣！當然好的注釋是非常必要的，否則别人的代碼就算像是自己寫的代碼，一個月後估計就隻有上帝能看懂了。
我以為這樣做還有個好處就是“一次制定，終身受用”。比如開發某大型商用軟體，如果開始能夠統一代碼規範，那麼即使最初的開發者離職了，接手的新人也能夠從統一的規範中快速入手并進行同樣規範下的源碼修改。通過遵循一緻的風格，此種規範能夠讓其他開發人員的介入、幫助、維護或新的發展變得高效有序。而且代碼規範具有極高的複用性，在不斷的實踐中總結出一套好的規範集，能夠在許多大型軟體開發前就做出限制與規定，這樣對以後的每個軟體開發流程都有非常好的影響。
并且，統一風格利于尋找bug。在做代碼審查的過程中，規範一緻的代碼對于審查的效率提升有莫大幫助。想象一下你看這一堆你覺得像坨屎一樣的代碼進行code review的時候會有多好的心情嗎...還會想着認真尋找bug嗎？看都不想看，還能讓人好好review嘛！
最後，我覺得是對于程式員個人的一種收獲。編碼規範的統一更利于程式員自身主人翁意識的培養，這種意識的培養我覺得是工程師與碼農的很大差別之一（純屬個人意見）。能夠對自己的代碼負責，就能夠開發出更加高品質的代碼，對于工程師本身也是能力的鍛煉。如果開發者從來不管代碼後續的維護問題，不管源碼的可閱讀性問題，那麼對他而言碼代碼隻能算作是一種工作，而從來不能稱之為藝術。
Q2：我是個藝術家，手藝人，我有自己的規範和原則。
A2:
代碼書寫過程中所遵循的編碼規範，有時就好像是一個作家在書裡的寫書風格。它們的共同之處當然有：它們往往容易被忽略，隻有少數人才能夠嚴格地遵循它們，并且這些人最後往往能夠成功。但是它們當然也有着巨大的不同：作家寫書是單兵作戰，而工程推進大部分時候是團隊合作的。
問題所述的情景在很多軟體開發過程中都會很常見。許多程式員都以自己的編碼風格為傲，有些甚至是為了代碼而代碼的。将本來邏輯清晰的代碼寫得複雜又難懂——這樣或許能為他在部門經理心中的地位的提升做出很大貢獻？或者隻是為了裝x(捂臉)？...隻是調侃一下：D。複雜晦澀難懂的代碼，或者說句法怪癖，基本不可讀的代碼，是很難得到他人的認同與維護的。能力與創造力和是否堅持自己的怪癖規範沒有半毛錢關系。
當然傳統軟體工程開發裡不乏很多單兵作戰的例子，比如Ken Thompson、Linus Torvalds、還有Donald Ervin Knuth教授“排版不爽就做個Tex”的讓人津津樂道的故事。确實，上個世紀湧現出的這些享譽世界的Hacker們，确實是以一己之力震驚世界的程式員的典範，是真正的程式員。
但是，他們是藝術家，然而我們現在并不是。藝術家往往是富有靈感與創意的，但是藝術家是有前提的：必須得有足夠的天份與更多的練習。也就是說：首先你需要是個匠人，然後你才可能是個藝術家。
作為一名solo developer，渴望成為superhero而獨立開發軟體，在現代軟體工程的複雜程度下，基本是不可行的。開發初期，我們可能會因為自己可以随意制定規範與原則而感到效率極高：不需要跟别人開發的子產品耦合，不需要“被迫”寫注釋，不需要花“大量的時間”去改變自己原先的編碼規範而适應團隊的編碼規範，不需要做大量“無用”的交流工作。
但是作為一名獨立開發者最大的好處同時也可能是最大的壞處就在于兩個字：自由。時間越長，對于獨立的開發人員來說一個軟體的釋出就越困難。除非開發者本身本來就有詳盡的知識技術、可行的解決方案和大量開發的經驗。但是現實往往是殘酷的，每個人都會有自己的思維盲點，在開發中這是避免不了的。我的觀點不是說某個人不能開發一個小的軟體，我的意思是說，一個人在付出足夠多的努力成為“藝術家”之前，軟體開發流程往往會因為設計的局限與解決方案的不準确而被迫停止。
而且，對于軟體的開發流程的推進，除非開發者是一個非常自律的人，不然可能遇到某個大的bug開發者就會喪失後續開發與維護的想法了。但是如果是在一個團隊中的話，大家可以一起想辦法解決bug，至少不會讓開發者喪失後續開發的信心。
是以說，每個開發者在想要一直保持“自己的規範與原則”前，需要認真地考慮一下自己是否真的是工程開發中的“藝術家”。如果還不是，那麼就必須遵守團隊的編碼規範；如果是，等到成為“藝術家”的時候，開發者自己也應該明白團隊編碼規範一緻的重要性了。
Q3：規範不能強求一律，應該允許很多例外。
A3：
世界上确實沒有完美的适用于各個軟體開發的規範，這是正常的。如果一個編碼規範能完美适應大部分軟體的開發，才是不正常的：因為這種相容性而導緻的要麼就是編碼規範集的急劇縮小，或者是不能适應它的軟體團隊推倒重新制定一套新的編碼規範。
但是，實踐開發驗證過的編碼規範确實可以提高生産效率，或者說，自己完全重新定制一套編碼規範有時并不如采用某種相似結構的編碼規範來得高效。這不僅僅是由團隊本身的實力決定的，更是因為實踐過程中使用過的東西更具有執行力。完全新的編碼規範，就好像溫室的花朵，可能在軟體開發過程中團隊要不停地對這種規範進行修改——甚至是重新來過，花朵最後可能就隻剩綠葉還留着——根本的東西已經沒了。這種規範制定上的錯誤有時候是緻命的，而且很多時候重新從頭制定會産生各中奇奇怪怪的編碼規範：
http://stackoverflow.com/questions/218123/what-was-the-strangest-coding-standard-rule-that-you-were-forced-to-follow
是以我比較贊同的是在軟體開發中，以前人的經驗實踐過的編碼規範作為基石——就像是泥塑的前期形态已經定好，輔以根據開發的軟體的特色、架構等制作的擴充規範編碼——就像是為泥塑精細雕琢一樣。隻有這樣，才能在保證編碼規範的大方向走對的情況下，走出自己的編碼規範的路。這樣，不論我們走的是小道，山道或者不從道上走，都能走上正确的歸途——前人早已經用腳為我們走出為了成功的方向。這麼寶貴的精神财富，何苦不用呢？
Q4：我擅長制定編碼規範，你們聽我的就好了。
A4：
其實我覺得這句話，和下面這句話的效果并沒有什麼不同：
我擅長吃飯，你們的飯都讓我來吃就好了。
編碼規範不是一個人能決定的，就像一個團隊——也不是一個人能決定的。在一個團隊裡大家确實要有所分工，各司其職，但是有些東西必須大家一緻同意才能決定——比如團隊例會時聚餐的地點、菜品的口味等。編碼規範就像是飯菜的口味一樣：确實有吃貨可能會選到很好吃的飯店——對他自己而言，但是對于其他人呢？
這就相當于一個北京的同學拿着一盤炸蠶蛹，廣東的同學端着一盤爆炒田雞給你吃一樣——他們确實選擇了他們喜歡的，但是你并不一定喜歡，有時候反而非常讨厭。因為對于他人來說美味可口的東西對你來說未必下得了口。是以對于那些自稱擅長制定編碼規範的同學來說，他所制定的編碼規範可能确實看起來風格很好，很美味，"很多人"都喜歡。但是他現在要滿足的不是"很多人"，而是"團隊"的口味。個人在這一點上務必要為團隊的統一與規範做出讓步。
這種心理更多地出現在這樣的開發者身上：抱怨不是因為制定的編碼規範不好，而是出于"我"比制定編碼的人更優秀，"我"不能被比我差的人所制定的規範所束縛的心理。這樣的開發者大多數覺得自己的代碼會被一個loser所制定的lower的編碼規範所拉低，是以實際上，他們的抱怨往往來自于心理失衡，而不是規範本身的問題。為了有這種"人上人"的體驗，他們往往想要制定編碼規範來lead别人，就好像他們制定了編碼規範就能鯉魚躍龍門——成為小組組長、部門經理、公司CTO一樣。
這種态度本身是帶有傲慢、虛榮心的，如果一個開發者想要實作這樣的"規範獨裁"，那麼他必定隻是一個蹩腳的開發者，更遑論是小組組長、部門經理、CTO了。真正優秀的開發者是謙虛、禮貌以及能夠為團隊做出犧牲的。不懂得融入團隊，天天把别人當傻x的開發者，往往自己一直扮演着最傻x的角色。