Coding Style 重不重要？一個資深工程師的觀點
你是否曾花費大量時間與同事爭論該使用單引號還是雙引號，或是該使用 Tab 鍵縮排還是空格鍵縮排，以及大括號是否應該換行等等？今天我要告訴你一個殘酷的事實，那就是：不重要。但為什麼其實又很重要呢？這兩個看似矛盾的說法，讓我來解釋解釋，這可能會顛覆你對 Coding Style 的看法。
個人經驗分享
如果你是第一次來到這個頻道，嘿唷，我的名字是 Bruce。我從事軟體開發已經十年，期間曾在新加坡工作一段時間，後來回到台灣創業，經營線上課程平台也已經六年。我曾經很堅持 Coding Style 一定要一致，要有意識地選擇某些 Coding Style，因為這個 Coding Style 比較好。但隨著工作經驗增加，甚至自己創業了，我最終改變了我對 Coding Style 的看法。
Coding Style 的重要性
Coding Style 為什麼重要呢？它有幾個常見的理由：
- 避免潛在錯誤： 例如，在某些程式語言中，不小心將
==打成=，會變成賦值操作。這種情況下，如果犯了這個錯誤，程式會直接崩潰，而不是執行後才默默修改數值。 - 提升協作效率： 因為大家都採用一樣的 Style，每個人就不用花很多認知資源，在熟悉風格有點像又有點不一樣的程式碼上，讀取時會比較順暢。
- 減少不必要的程式碼變更： 避免因為 Coding Style 不同，導致 Code Review 時反覆修改同一段程式碼，浪費時間且讓 Git 歷史變得混亂。
- 簡化程式碼變更： 例如，如果有多行的 Array，你決定在最後一個結尾加上逗號，那麼當你把倒數第二個和最後一個元素互換時，你只會更動到一行，而不是兩行。
這些東西當然都很重要，但是跟一些其他事情相比，這件事情就可以說相對有一點小。
更重要的考量
例如，如果你有這世界上最棒的 Coding Style，但你根本沒有按照需求寫，你沒有解決實際的問題，那你解決出去的功能就會被需求方直接打槍說，你這個根本沒有按照我要的東西寫啊，那這樣子 Coding Style 有什麼意義呢？或者，你也按照需求寫了，然後你的 Coding Style 也非常棒，但是當初推出的這個產品根本不符合市場需求，所以產品推出以後大爆死，營業超爛，然後公司倒閉，然後就收掉了，那這樣子又有什麼意義呢？
這時候你可能會問：按照需求方提出的東西是一回事，要符合最終使用者的期待，要符合市場需求是一回事，但 Coding Style 也是一回事啊，這兩個是獨立的事件，其實兩個都可以做不是嗎？但我認為 Coding Style 很重要這件事情，其實是過譽了。
Bikeshedding 效應
這邊要講一個很有名的故事，就是 Bikeshedding 的故事。有興趣的話可以去 Wiki 上面查一下這個故事的起源，但是我現在講一個最簡化的版本：有人要蓋一座核電廠，這個核電廠裡面當然就會有很多核能相關的東西，就是各種核能工程相關的事情。同時呢，他還需要一個腳踏車停車場的棚子。他就找委員會來開會嘛，因為大家就不知道那個核能很重要的那些東西，就你如果亂給意見到時候採用你的意見出包，對不對，就很麻煩啊。明明是非常重要的部分，但是卻三兩下討論完，然後就，啊 ok... 就放行了。但是大家卻在那個腳踏車棚子要漆什麼顏色，爭論了好幾倍的時間。這顯然不是很合理嘛。
偏偏呢，選擇 Coding Style 要用什麼的這件事情，特別容易發生這樣子的狀況，因為畢竟它確實是有點價值，它確實可以帶來一些幫助，而且決定這件事情並推行然後採用，這也是非常有成就感。問題是凡事都有代價，你做了，花時間心力在這件事情上，你就失去了做這件事情的機會。那這兩件事情呢，往往就是做這件舒服，然後做起來很爽很有成就感，然後有很快得到價值，但邊際效用就是下降的很快，所以很快的他就總價值變得上不去了。
另外一種呢，就是那件很痛苦的事情，你不想面對，但它很重要，但不緊急。一開始很難看到(成效)，我覺得它學習曲線很高，或者你在推動飛輪的時候，它一開始轉得非常慢，但是一旦轉起來以後，它是一個非常高價值的東西，前期的投入最後能夠產生超出很多倍的回報。那你在這兩種事情之間的選擇，去搞 Coding Style 就有點像是這裡的事情，而會容易讓你忽略那邊的事情。
如何處理 Coding Style？
那怎麼辦？難道就是把 Coding Style 就不管了丟掉這樣嗎？工作這麼久以來，我現在的解決方法是：
你應該先花一點時間，不要太多，花一點時間，去尋找研究一下你所使用的程式語言裡面，有沒有一個官方的或最流行、最主流的 Coding Style 的規則，而且就是完全就遵守，即使它跟你原本的習慣有點不太一樣，反正你就是遵守。那這樣子你就不用再去考慮，我是不是應該採用這個，因為這個比較好，因為什麼原因比較好，然後還要說服別人去採用這個方法，而是你採用、你的團隊也採用、大家都採用，那你就不用去想這些事情，然後也不會有那個大家 Style 不一樣，所以常常需要花一點認知資源在上面這件事情，就不成立不會存在，因為大家都採用一種。
可是呢，這個時候又會有一個常見的問題，如果這個選定的 Style 大部分都很好，偏偏就是有那麼一兩個真的是生理上無法接受，真的是醜爆了怎麼辦？
這邊會分成幾種情況：
- 習慣就好： 實際上呢，人是一個非常能夠習慣的動物，很多時候用這個好還是用這個好，那個所謂的好，只要有超過一個基本的水準，在這個之下叫真的完全就是錯誤，在這個之上，其實就是一個不見得哪一個是對錯。也就是說呢，你就放棄你的自尊心，就採用，就 OK 了。
- 了解背後的原因： 這已經不是習慣不習慣的問題，我採用這個東西，它就是會有容易犯錯的問題啊。就像例如說，我如果是堅持 Yoda Condition 派的人，然後我採用的那一個其他都很好，但在 Yoda Condition 這件事情上跟我意見相反怎麼辦？這個時候要知道很多事情，通常都是它可能有它的道理，你有你的道理，那你應該去了解它的道理在說什麼，說不定你真的去了解它的道理之後，你會被說服，那這樣就解決了嘛，就是你就不會有那個生理上無法接受的問題。
- 取捨： 比這個再更複雜，難解決的狀況是，就仍然是有那麼一兩個東西是跟你的習慣不一樣，就是不一樣，然後無法接受，就是你也沒有被說服。在這個狀況呢，你就要考慮是不是放棄這兩個堅持，就是你真的沒有被說服，它也真的還是有問題，但是因為你採用了這個以後，你可以得到一些協作上的好處，然後不用去煩惱那麼多，然後減輕一些認知負擔 which 是非常重要的事情，這等於就是你的犧牲打，然後讓你可以得到其他好處，那這個犧牲值不值得？那通常呢，很容易是值得的。
因為如果就那麼一兩個問題嘛，那軟體開發協作呢，跟很多其他事情一樣，一旦複雜到一個程度以後，一定會有一點兩難，兩難的時候，就沒有黑白或者是對錯的這種簡單的標準答案可以依循，你勢必得做出一點取捨。