很多程式設計師喜歡爭論程式碼風格。別否認哦，類似的話題總能吵起來。Bill Sourour 認為：程式碼風格沒有絕對的對錯，只要團隊程式碼風格統一就行了。Bill 覺得比較安全的做法：① 通過工具自動規範程式碼風格；② 參照名聲好的大公司使用的程式碼風格。
- 用製表符（Tab）還是空格（Space）？
- 在同一行中使用大括號，還是新起一行？
- 每行是 80 個字元，還是 120 個？
程式設計師都喜歡爭論這型別的事情，製表符和空格的爭論，甚至在 HBO 的《矽谷》中出現了。
對於這些爭論，在這篇文章中，我最後會給出一個明確的答案。
在我的職業生涯早期，我也參與到了這些“聖戰”中。我會閱讀一些文章，來了解為什麼這個規範是正確的，而另外一個完全是錯的。然後趾高氣揚地對其他與我爭論的人說他們是錯的，而我是正確的。
尋找正確的答案，這花費了我多年的時間，並且我也找到了，但最終的答案就是……
這些事情無關緊要！
一致性很重要、可讀性很重要！爭論並強調某一個規範比另外一個規範好，都是一些無關緊要的事。
在過去的 20 多年，我關注了各種語言規範。並遵循了不同語言的不同規範。但是，沒有一個規範會減少我的 bug 數量，或者使我的程式碼效率更高。
隨著時間的推移，不使我犯錯、整潔、格式化的程式碼，更易於改動和維護，這就是好的程式碼。
想著如何把你的程式碼寫的更漂亮，這並不是壞事，但執著於此，常常會把問題歸根於此，併為自己的拖延找藉口。
實際上，我們如此拖延主要是因為編碼時遇到了難題。並且這個問題對當時的我們來說很難解決–尤其是當我們首次遇到這種級別的難題時，我們會被這種複雜的問題嚇到，導致我們懷疑自己沒有這個能力去解決它。
但如果是爭論一些瑣事，我們就會遊刃有餘、有安全感。因為在爭論瑣事的過程中我們的不自信 （perceived incompetence ）就不太可能暴露出來。
爭論一些瑣碎的事情而逃避那些困難的問題是一種常見的現象，這裡有大量著名的理論描述了這一現象。
有一個最著名的理論就是帕金森瑣碎定律 （Parkinson’s Law of Triviality），它描述了：一個組織中的成員往往會把過多的經歷，花費在一些瑣碎的事情上。
帕金森用了一個虛構例子來解釋了這個定律：在一個稽核新核電站計劃的委員會中，會員把主要的時間用於爭論員工自行車棚使用什麼材料，忽略了被提議的核電站計劃本身，而這個恰恰是最重要、最複雜的問題。
由於在這個經典的例子中使用了自行車棚來闡述問題，丹麥的開發者 Poul-Henning Kamp 創造了新的術語來描述這種現象，叫“自行車棚效應（bike shed effect）”，或者簡單地叫“自行車棚（bike shedding）”。
如果你從事軟體開發，特別是你在社交媒體上與其他程式設計師閒聊時，你可能每天都會遇到類似“自行車棚”案例（bike-shedding）
如果你發現自己正線上上或者線下中和程式設計師同事進行熱烈的爭論時，你應該記住 Sayre 定律：
“在任何爭論中，主觀上的重要程度，往往和問題的實際重要程度成反比。
作為一個顧問/諮詢師，我在不同的客戶之間奔波，他們都有自己的規則和習慣。因此，在很久之前我就堅定認為，成功的唯一方式就是，放棄瑣碎的事情，專注有挑戰的問題。把它應用到編碼規範上，我就可以收穫到我想要的東西，並且不會變得浮躁。
如果你正在尋找一種屬於自己的程式碼風格，我建議你先問自己兩個問題：
- 是否有現成的工具，只需簡單操作，就可以自動按照你的程式碼風格規則，來格式化程式碼？
- 這個工具以及它支援的程式碼風格規則是否有人在持續維護，或者是否有一些知名公司在用？
對於上面的兩個問題，如果你的答案都是“是的”，那麼你就可以放心用這個程式碼風格。就是這麼簡單。
下面有一些程式碼格式化工具：
- DotNet Code Formatter
- Java: Google-Java-Format
- Javascript Standard Style (注意，這只是一個產品名，不是 JavaScript 官方的標準)
- PHP Coding Standards Fixer
- Python: Google’s YAPF
- Ruby: Rubocop