談談編碼風格與編碼規范

jopen 11年前發布 | 16K 次閱讀 編碼規范

談談編碼風格與編碼規范

        @玉伯也叫射雕

        引子

        上一篇文章提到 「習慣與變化」,收到了比較有意思的一些反饋:

我很好奇,如果你的團隊中有人以“習慣”的名義打破編碼規范會怎樣?于我而言,不寫四直接寫五就是這種感覺,這并不是習慣,而是規范。

        還有一封很長的郵件,截取一二:

玉伯哥,我經常會為一些事情糾結,比如創建文件夾的時候會想是首字母大寫好看呢還是全小寫來保持統一呢 (Movie,movie,mytest,MyTest),當寫程序注釋的時候我會想是寫 // this function proves that... 好呢還是 // This function proves that... 我不知道我這種對大小寫在意的習慣是一種好習慣還是一種壞習慣……

        微博上,一提到編碼風格時,往往也會引起腥風血雨,比如

  1. JavaScript 語句后面應該加分號嗎?
  2. 縮進應該用 Tab、四空格還是兩空格?
  3. 變量應該統一提前聲明好還是就近聲明?
  4. 變量名應該用駝峰風格還是下劃線風格?
  5. 注釋應該采用 JSDoc 風格還是 Markdown 風格?
  6. 私有屬性約定用下劃線開頭嗎?
  7. 函數最好不要超過多少行?
  8. ……

        這類問題不僅在程序員中普遍存在,文字工作者也常常糾結:

  1. 中英文混排時,中文與英文之間應該加空格嗎?
  2. 中英文混排時,英文字母后面應該用全角還是半角標點符號?
  3. 段落前面真有必要空兩格嗎?
  4. 引號是否應該用 『』和「」?
  5. 破折號是一杠還是兩杠?
  6. 例如、參考等詞匯后,究竟需不需要加冒號?
  7. ……

        風格

        我們日常說的編碼規范,經常指的是 Style Guide,正確的翻譯是編碼風格。

        既然是風格,就沒有對錯。就如現實生活中,我們每個人都有自己的穿著打扮一樣。可能有些人打扮土一點,但土就土,并不影響什么。

        很有意思的是,風格也沒有孰優孰劣。比如郭敬明的打扮,很多人很喜歡,會為其尖叫為其瘋狂。但在我看來,郭敬明的相貌讓我非常討厭,這還是男人嗎?太銼啦。

        別去爭辯,喜歡和對錯無關,風格亦無高低之別。

        編碼風格如此,文字排版風格也是一樣。

        規范

        風格之外,也有規范。比如穿著打扮,光怪陸離都沒問題,但在公眾場合不能不穿。規范經常很少很少,但的的確確存在。

        對于 JavaScript 語言來說,通用的編碼規范基本沒有,有的話只有一條:要能運行。除此之外,還會有一些:

  1. JavaScript 文件的編碼必須是 UTF-8 。
  2. JavaScript 中不能出現 URL 硬編碼。
  3. ……

        以上規范都是針對具體公司具體場景下的要求,除了以上這些規范,其他都是編碼風格問題。

        社會中的規范,是為了維護基本秩序和道德底線。編碼規范,則是為了避免錯誤。

        態度

        程序員經常有個壞習慣:拿到別人的代碼,喜歡首先按照自己的風格格式化一下。特別是用 Vim 的程序員,有些 Vim 程序員不光喜歡格式化他人的代碼,還會在文件頭留下作案憑證。

        好的習慣是這樣的:

@agentzh: 給他人的開源項目提交補丁也是一樣:盡可能多地做足功課,弄清楚該項目使用的代碼風格和測試集的組織,甚至是 git 提交日志的書面格式,盡量讓我寫的東西酷似項目作者本人寫出的東西,這樣可以節約對方的時間,是對他的最大尊重。

        這就如我們去朋友家里做客,你可能會很不喜歡朋友家里的裝修風格,但你最好不要自帶顏料桶去幫朋友重新裝修。道理不用多說,對他人的風格我們要懂得尊重,無論是在現實生活中,還是在寫代碼時。

        當然,認可的規范還是得遵守。比如別在公共場合裸奔,別在一個 UTF-8 團隊把文件存成 GBK 編碼。

        對待規范,要嚴格遵守。對待風格,要懂得尊重。

        關鍵

        一旦你擁有了開放的心態,一旦你開始懂得去欣賞他人的風格,你會發現世界是五彩繽紛的,你會開始越過一些表象,關注起一些真正值得關注的。

        比如一個長得很丑的人,當你不再去看外表時,你會發現某些情況下丑人是會發光的,那種光十分漂亮,比很多帥哥漂亮百倍千倍。你會開始懂得生活,懂得真愛。

        編碼也如此。不再去糾結四空格還是兩空格后,你會看到

  1. 代碼的邏輯抽象是否正確?
  2. 代碼背后的數據模型是否可以優化?
  3. 這段代碼是否應該放在這個文件里?
  4. 這個模塊的職責是否過大?
  5. 這個設計模式是否用得太僵硬?
  6. 某個功能點是否應該用 CSS 而不是 JS 來實現?
  7. 這段代碼是否忘了寫單元測試?
  8. ……

        一旦你開始能從他人的代碼中,去糾結以上各種問題而不是代碼風格時,你的功力經常就會大增。牛逼的程序員有個不怎么對外說的秘密:

去更多地看代碼,看優秀的代碼。迫不得已才自己去寫少量代碼。

        最后

        代碼如人,風格的差異很正常,彼此尊重。相愛是靈魂的碰觸,別停留在表象。

來自: github.com
 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!