摘要：仁者見仁智者見智，編碼風格的不同，對項目也會有不同的影響，統一的編碼規范有益于項目的維護。俗話說，沒有規矩不成方圓，在2004年，UNIX創始人之一的Ken Arnold就發表了一篇很幽默文章：Style is Substance，文中強調了編碼風格的重要性。

大家是否發現把時間浪費在討論編碼規范的分歧上，事后又覺得那些都是徒勞無功的事情。

每個人都希望有人贊賞他的編碼風格。就像多年前的我一樣，在那時（相對于今天來說），C語言還是那種擁有多個競爭風格的語言。這里有K&R風格，但從未引起我的興趣并且當時還有其他需要編譯的事情。有些人開發是基于一種美學的編碼風格，還有的基于可讀性或者其他方面的——采用堂吉訶德式的信仰來編寫，if（4==y）的這種風格，可以提高代碼的正確性。我個人的編碼風格是從那個時候開始的，我擁有一個屬于自己的C語言雜志，為了讓代碼盡可能清晰的打印在雜志上，所以我盡可能多留一些垂直空間并且在操作符號周圍多使用一些空格。即使今天，代碼打印出來后仍能清晰地閱讀。Java代碼編寫風格也這樣。C語言編碼風格繼承并稍作些調整，但至少對于我來說，打印效果還是非常棒。

在我工作過的許多網站都進行過長期地討論，怎樣才是最好的編碼風格？我見過許多開發人員抱怨被迫采用一些規范，使他們的語法和語義被破壞。對于這些規范，甚至多年前，我的感覺就像是一個成年代碼保姆。關于這種辯論的核心莫過于可選字符的使用、大括號位置、代碼塊如何縮進、空白空間的大小、注釋格式以及語句聲明等。鑒于如此豐富的細節，任何帶有偏好的明智組合都不可能提供如此高的競爭性集合。這根本是不值得進行討論的。

有一個比較重要的問題是，在一個不同理論風格的網站下面，開發人員允許使用彼此最舒服最擅長的編碼風格，這樣就會導致如下幾個問題：首先，有些程序員的編碼風格會很奇怪；其次在一個代碼庫里面可能有多種編碼風格，代碼很難讀尤其當多個人去維護的時候；最后，在代碼被維護或者更新的時候，許多開發人員會根據他們的喜好重組代碼塊。這些會使一些毫無意義的增量在代碼里面生成，這樣維護起來不僅僅浪費時間，而且會讓代碼越來越亂，反而增加維護成本。

采用單一的編碼風格是網站最佳的解決方案。堅持統一的編碼風格是至關重要的，但很少有兩個網站或者公司的編碼風格是一樣的，所以當開發人員加入到新團隊以后，還是會浪費一些時間。在我看來，最佳的解決方案是讓語言設計者在設計時盡可能地多采用些風格，這種方法可以大大方便閱讀和代碼編寫，語言設計者已經慢慢認識到它的好處。在早期的語言中，例如上面提到的C語言，但是Fortran卻更加瘋狂，它甚至在關鍵字后邊都不需要留有空格，這使得各種各樣的形式都涌現出來，并且還移交給那些不幸者維護了幾十年。

不過在近期，語言已經加強了這方面的要求。Python對代碼塊有非常嚴格的縮進風格。谷歌的新興系統語言Go，對括號的打開有了位置要求：在新行上，它們不可以成為第一個字符。某種意義上來說，Go語言的打開括號已經解決支持K&R這種編程風格。更重要地是，Python開發人員并沒有對縮進有所抱怨，就像新興Go程序員一樣，對括號位置沒有任何怨言。

這種可接受性表明，開發人員變得更加明智——承認風格一致性所帶來的好處以及多樣性所浪費的成本。追求這種主題，語言設計者將朝著這種方向走的更遠。如今代碼庫已經越來越大——本周將完成1000萬行代碼，這絕對不是個非常大的數字——編譯后擁有統一的代碼風格并且強調可讀性和刪除那些“喋喋不休”的代碼在很久以前就已經解決。作為一個單獨的個體來說，我很愿意拋棄我已使用多年的編碼風格來滿足那些單一的、可讀的、可委托方法的代碼。

總結

以上是生活随笔為你收集整理的我们真的需要统一的编程规范？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。