軟件質量，不但依賴於架構及項目管理，更與代碼質量緊密相關。簡潔高效的代碼不但易於閱讀，更能避免潛在 Bug 與風險，提高代碼質量。這是顯而易見的道理，但是要做到這個標準可不容易。想想看，據說 Oracle 12.2，有近2500萬行代碼，是不是很恐怖？你能做到在不破壞成千上萬個現有測試的情況下更改這樣產品中的單單一行代碼嗎？很難，對吧？要想避免這樣的情況，就要從源頭做起。“30”規則就是一個很好的辦法，讓我們看看 Riccardo Giorato 是怎麼說的？
正文：
本文最初發布 Medium 博客，經原作者 Riccardo Giorato 授權，InfoQ 中文站翻譯並分享。
如果你在編程中，不考慮代碼長度的話，那麼可維護性、未來更新或對代碼庫的更改，都將會變得異常困難。
方法或函數的大小應該多大呢？
我們都遇到過這樣的問題，當一個函數太長的時候。
或者類，或者包，或者任何其他代碼塊。在某些情況下，任何一段代碼都有可能會變得過於龐大，以至於他人無法正確理解。但是，多大才算大呢？
在 Code Complete （《代碼大全》，金戈等人譯，電子工業出版社）， Steve McConnell 指出，理論上，一個方法或函數的最佳最大限制是在一個屏幕上可以容納的行數。
這種“適合屏幕”的尺寸相當於 65~200 行之間的函數的最佳點。這種大小的例程開發成本更低，每行代碼的錯誤也更少，而且它們的可維護性也很高。
如果你寫的代碼超過了 200 行，那麼，你就會進入了“危險區”：代碼的可讀性和正確性即將開始崩潰。
30 行代碼規則
找尋找更嚴格的指導原則時，你可以在 Stephen Roock 和 Martin Lippert 合著的 Refactoring in Large Software Projects（《大型軟件項目的重構》，暫無中文版）一書中找到“30”規則：
如果一個元素包含超過 30 個子元素，那麼極有可能會存在嚴重的問題：
a) 方法的平均代碼行數不應超過 30 行（不含行空和註釋）；
b) 一個類應該包含平均少於 30 個方法，最多可以包含 900 行代碼；
c) 一個包包含的類不應超過 30 個，因此最多可包含 27000 行代碼；
d) 應當避免使用超過 30 個包的子系統。這樣一個子系統最多包含 900 個類，810000 行代碼；
e) 因此，一個有 30 個子系統的系統，將擁有 27000 個類，2430 萬行代碼。
你應該遵循這些規則嗎？如何做？
使用代碼大小作爲編碼規則還是非常友好的；對於每個開發人員來說，無論年輕還是碾場，都很容易看到、理解。其他度量，如用於度量代碼質量的循環複雜度（cyclomatic complexity），通常更難掌握，並且需要外部工具進行檢查。
將類或函數長度限制在這些值範圍內將是一個更好的起點，而不是對你的團隊或開發人員沒有真正的參考。你還會發現，當你審查或更新代碼時，這“30”規則的真正價值是顯而易見的。
試圖將這些規則作爲法律或強制性規則來執行，反而會讓你置於危險之中——這並不是他們的目標。當你在編寫方法中寫到第 31 行時，你不會希望停下寫代碼，對吧？
此舉將會降低工作速度，並迫使每個人都將代碼分解以適應任意的大小限制，這將使他們的代碼風格變得更糟，而不是更好。
正如 Jeff Langer 在討論 Ken Beck 在 Clean Code（《代碼整潔之道》，韓磊譯，人民郵電出版社）一書中提到的簡單設計的四條規則那樣：
我們的目標是保持函數和類短小的同時，保持整個系統短小精悍。不過要記住，這在關於簡單設計的四條規則裏面是有限相機最低的一條。所以，儘管使類和函數的數量儘量少是很重要的，但更重要的確實測試、消除重複和表達力。
有時候，要完成一份連貫的工作需要 30 行或多或少的的代碼。
更重要的是，在編寫類時要小心，要考慮自己在這裏添加了多少東西，其他人會理解這些結構和函數的分組嗎？我應該分割這個文件呢，還是講這個類與另一個類合併呢？
“30”規則將會給你帶來幫助，但你必須不能讓它支配你！
參考文獻和資料
- https://stackoverflow.com/questions/475675/when-is-a-function-too-long
- Code Complete（《代碼大全》）
- Refactoring in Large Software Projects* */ Rule of 30（暫無中文版）
- Clean Code（《整潔代碼之道》）
作者介紹：
攝影測量師，網頁開發人員。
原文鏈接：
The rule of 30