方法重構

Question

在您需要更好地設計之前，方法可以使用多少行代碼進行良好的設計？

Answer 1

代碼行是用於重構的不完整度量。 Cyclomatic Complexity應與LOC結合使用，作為何時重構的合適標准。

一個體面的指導方針是

LOC > 80 || CC > 10 == "Time to refactor"

在你達到80行代碼之前，你很可能會遇到一個> 10的Cyclomatic Complexity。

當然，還有一些其他指標需要考慮：

1. 傳入耦合：有多少方法依賴於此方法
2. 傳出耦合：此方法依賴多少種方法
3. 參數數量
4. 使用的Varialbes數量

你可以深入探討，但所有這一切都說明，確定何時重構不能用一條全面的規則決定，比如“你不能用任何方法超過40行！”

Answer 2

沒有被接受的規則。 它應該盡可能簡單易讀。 如果這意味着占用10行的5行並將它們放入自己的方法中，那就這樣吧。 但有時候，使用50行方法可能會很好。 在6個月的時間里做你認為最能理解的事情。

Answer 3

取決於該方法的作用。 在編寫太少的方法和太多的方法之間有一個很好的界限，其中大部分都是個人品味的問題。

我的意見：

• 對於一種方法，50行太長。 我認為比這更短的方法通常也太長，但這是我方法長度的最高閾值。
• 應編寫方法，使其不止一次使用。 不要僅僅為了縮短現有方法而進行重構; 重構以制作其他方法將受益的可重用方法。

在需要重新設計方法之前，方法可以擁有的代碼長度沒有任意限制。 但是，通常情況下，如果方法感覺“太長”，則表明您做錯了。

Answer 4

這不是一個規則，但作為一種啟發式方法，當一個方法超過25行時，我給它一次，看看我是否可以將它分解為更簡單的組件。

這並不是說超過25行的方法從來沒有很好地設計，或者較短的方法總是比較長的方法更好。 這只是一個很好的啟發式方法。

Answer 5

盡可能多地邏輯和清楚地執行方法執行的單個任務。

說真的，沒有標准。 通常人們喜歡能夠在他們的顯示器上的一個頁面內看到整個方法，因此這是一件需要考慮的事情。 但行數並不是邏輯問題的主要指標。 太多的開發人員對代碼進行了模糊處理，並且通過嘗試將代碼盡可能少地編入代碼來使未來的支持變得更加困難。

如果這是邏輯上和清楚地執行該任務所需要的，那么單個方法中的1000行代碼就沒有任何內在錯誤。 這種情況很少見，長期通常是重新考慮因素的方法，但這種方法是可能的。 也有一些是內在的錯誤1000行的面條代碼都在做不同的事情，在一個單一的方法奇特的方式進行交互。 行數不是問題。

Answer 6

也許，我們應該考慮通過這里的方法實現“責任”，而不是通過硬數字來實現。 如果我們嘗試將方法限制為單一責任，LOC將自動處理。

我們可以遵循的另一個經驗法則是限制我們可以在單個屏幕上看到的方法的長度。

Answer 7

代碼行是一個度量標准，而另一個代碼是代碼路徑。 每個if，和，或循環等使函數更復雜。 您可以擁有非常簡短的復雜功能，並且可以使用簡單易懂的功能。 使用它時，重構效果很好，降低了復雜性，而不一定是代碼行。

例如：

if (color.r == color.g && color.r == color.b)
    if (color.r > 128)
       newColor = color.White;
    else
       newColor = color.Black;

VS

if(isGray(color))
   newColor = thresholdGray(color)

意圖更清晰，路徑數量減少。

Answer 8

確實，LOC是一個糟糕的指標，因為它與你真正感興趣的屬性（設計質量）沒有很好的相關性。 但它作為衡量指標的巨大優勢 - 以及如此廣泛使用和討論的原因 - 當然是多么容易衡量。 那不是純粹的懶惰; 只需百分之一的努力，你就可以得到 - 好吧，可能是更有意義的指標價值的20％或30％。 您只需瀏覽一個方法或類的最后一行，然后評估LOC指標。 你可以看看滾動條的高度，並有一個非常好的主意。

並且有真正的LOC限制是有意義的 - 太多而無法放在顯示器上或文本頁面上，實際上太多了，盡管簡單和凝聚力。

我喜歡很簡短的方法。 單行很棒。 當一個方法開始進入兩位數LOC時，它會發出癢聲。 如果它是30或更多，那很痛苦。 繼續使用LOC; 只是將其弱點理解為度量標准，並了解存在哪些更好的指標（例如圈復雜度）。 當你需要更好的東西時使用它們。