知識星球（點選上方公眾號，可快速關註）
英文：Ben Sourour，編譯：伯樂線上/周進林
【伯樂線上/程式員的那些事 導讀】：很多程式員喜歡爭論程式碼風格。別否認哦，類似的話題總能吵起來。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 （註意，這隻是一個產品名，不是 JS 官方標準）
-
PHP Coding Standards Fixer
-
Python: Google’s YAPF
-
Ruby: Rubocop
微信不支援外鏈，點選「閱讀原文」檢視上述工具
看完本文有收穫？請轉發分享給更多人
關註「程式員的那些事」，提升程式設計技能
