在〈如何導入 Code Review 〉有略提到程式碼風格的議題，提到程式碼風格應該透過自動化去檢核，而不是在每次 Code Review 時仰賴人工審核。然後在《為團隊與組織導入敏捷的經驗分享》 系列文中的〈制定一個可落實的政策〉也有提到下面這段話，因為和本主題相關，就一併引用過來集中資訊：

一次要針對所有程式碼都統一風格，可能會因為範圍太大，有點窒礙難行，所以可以先限縮範圍在 JS 的程式碼，然後只有新的 Commit 需要遵守，先不溯及既往，不然光是重構就瘋了。

再來是要遵循怎樣的風格，有人喜歡 AirBnB 的風格、有人喜歡 standardJS 的風格，可能是先選擇一個作為標準去遵循，那可能就是讓幾個目前比較活躍的 JS 專案嘗試看看，編寫一個腳本去只針對 Git 顯示有變動的部分去透過 ESLint 檢查是否符合風格。

這樣不斷的限縮範圍和補完後，一個可落實的政策就差不多完成了。接著可在訂定一個在哪一天大家再重新檢視這個專案是否要修改，或是有什麼地方可以讓大家提出想要修改其中哪一條風格設定，讓原本遵循的風格更具團隊特色等等。

上面講的這些話，大致把團隊如何導入程式碼風格的方式做個建議，這邊在簡短的總結、補充：Code Review 應該透過 Lint 來進行，並透過 CI 進行自動化檢測，只讓通過檢測的變動可以併回主線。程式碼風格可以先選擇一個標準，再逐漸修改成團隊自己喜歡的風格。另外補充，除了先選擇一個標準外，也可以從零到有，讓團隊在每次 Code Review 提出一個統一建議，並且另外提出一個 PR 去將標準寫進設定檔，併入主線。

好，除了導入程式碼風格外，今天來聊聊另一個議題，也就是標題所言：「程式碼風格要點在於一致，而不是優劣」。

在軟體開發的圈子裡，有個很有趣的現象，就是大家都很喜歡戰語言、也喜歡站程式碼風格。誠然，有些程式碼風格會讓整體程式的可讀性增加，應該要盡快引入，但是在引入時，又有人會因為信仰不同，而提出另一個風格建議，最後兩方就開始吵誰優誰劣，甚至鬧到不歡而散。

但事實上，對團隊開發來說，程式碼風格的要點在於一致，而不是哪種風格比較好。舉個極端的例子，若是本來專案已經用了惡名昭彰的匈牙利命名法，新來的成員覺得不妥，提出改成了駝峰式命名法，後來又有新成員近來，覺得蛇式命名法比較好，於是又換了另一種風格。成員來來去去，風格可能也換來換去，當是在換風格時難免會漏改幾個，最後整個專案命名規則紊亂，那還不如全體都遵守匈牙利命名法比較好。

所有程式設計師應該都有有個認知，彼此對程式碼風格的喜愛不一樣是正常現象，重點是同個專案程式碼風格要統一，若是最後以投票表決決定某種程式碼風格，就應該要尊重團隊的決議。只有當風格統一時，彼此在閱讀其他人編寫的程式碼時才能比較輕鬆。

其實，程式碼風格就像是團隊的默契，也是會需要逐漸養成的。很難一開始就定義出一個完整的程式碼風格，所以會建議如前面所講，再逐次遇到對風格有歧異時，團隊約個時間一起坐下來討論，不同意見者發表各自支持的論點，最後彼此綜合這些意見，以投票或是團隊認同的形勢作出決定，再把決議寫進 Lint 設定檔中。若有些風格不是設定檔所能規範時，就寫在專案根目錄的某個文件裡。透過這樣逐漸訂定出團隊自屬的風格，讓彼此的程式碼讀起來就像自己寫程式碼一樣輕鬆。