100%正確的編碼風格指導

轉載:http://www.techug.com/post/the-100-correct-coding-style-guide.html?1496499243896


【導讀】:很多程序員喜歡爭論代碼風格。別否認哦,類似的話題總能吵起來。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 定律:

“在任何爭論中,主觀上的重要程度,往往和問題的實際重要程度成反比。

作爲一個顧問/諮詢師,我在不同的客戶之間奔波,他們都有自己的規則和習慣。因此,在很久之前我就堅定認爲,成功的唯一方式就是,放棄瑣碎的事情,專注有挑戰的問題。把它應用到編碼規範上,我就可以收穫到我想要的東西,並且不會變得浮躁。

如果你正在尋找一種屬於自己的代碼風格,我建議你先問自己兩個問題:

  1. 是否有現成的工具,只需簡單操作,就可以自動按照你的代碼風格規則,來格式化代碼?
  2. 這個工具以及它支持的代碼風格規則是否有人在持續維護,或者是否有一些知名公司在用? 

對於上面的兩個問題,如果你的答案都是“是的”,那麼你就可以放心用這個代碼風格。就是這麼簡單。

下面有一些代碼格式化工具:


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章