函數最多有多少行？

Question

是否有一種很好的編碼技術來指定一個函數應該有多少行？

Answer 1

對於任何事情來說，代碼行是一個相當不好的指標。這個例外可能是成千上萬行的函數 - 你可以肯定地說這些函數寫得不好。

然而，好的編碼技術通常會導致每個功能的代碼行數更少。諸如DRY（不要重複自己）和Unix哲學（「編寫能夠做一件事並且做得很好的程序，編寫程序來共同工作，編寫處理文本流的程序，因爲這是一個通用接口。維基百科）。在這種情況下，用「功能」替換「程序」。

Answer 2

，我不認爲它很重要，誰是說，一旦一個功能長度超過某個數量的行它打破的規則。

一般來說，只是代碼清理功能易於使用和重用。

Answer 3

針對具有是「太長」功能的主要論點是，細分功能爲更小的功能，只有做了整個工作的一小部分提高了可讀性（通過給這些小部件的實際名稱，並幫助讀者換他關注較小的行爲，尤其是當第1532行可以更改第45行中變量的值時）。

在功能的編程語言，這一點是沒有實際意義：

• 可以細分的功能成被較大的功能的主體內定義，並且因此不降低原有的功能的長度更小的函數。

• 函數應該是純粹的，所以沒有實際的X行改變Y行讀取值的實際風險：行Y變量的值可以很容易地追溯到定義列表中，即使在循環中，條件或遞歸函數。

所以，我懷疑答案是「沒有人真的在乎」。

Answer 4

函數應該有一個明確的目的。也就是說，嘗試創建完成一件事情的功能，可以通過自己完成或者將工作委託給其他許多功能來完成。

大多數函數式編譯器在內聯方面都非常出色。因此，分解代碼並沒有固有的代價：編譯器通常在確定函數調用是否應該是真正的代碼或者是否可以立即內聯代碼時做得很好。

函數的大小是不太相關雖然在FP大多數功能往往是小的，精確和對點。

Answer 5

有圈複雜度的麥凱布指標，你可能在這個Wikipedia article瞭解。

度量指標測量例程中存在多少個測試和循環。一個經驗法則可能是，在10以下是可控的複雜度，而超過11則變得更容易出錯。

我看到可怕的代碼，上面有一個50度的複雜性（這是容易出錯，很難理解或改變。）重寫它並將其分解爲子程序將複雜度降低到8.

注意複雜度度量通常與代碼行成比例。它會爲您提供複雜度而非代碼行。

Answer 6

我認爲一個長功能是一面紅旗，值得更多的審查。如果我在代碼審查過程中遇到了超過一頁或兩頁的函數，我會尋找方法將其分解爲更小的函數。

雖然有例外。一個包含大部分簡單的賦值語句的長函數，比如初始化，可能最好保持不變。

Answer 7

當在Forth工作（或在Factor中工作）時，我傾向於不斷重構，直到每個函數都是單行！事實上，如果你瀏覽因子庫，你會發現大多數單詞都是單行的，幾乎沒有什麼比單行更多。在一種具有內部函數和幾乎爲零的調用代價的語言中（也就是說，線程代碼隱含地沒有堆棧幀[只返回指針堆棧]，或者具有積極的內聯），沒有好的理由不要摺疊，直到每個函數很小。

Answer 8

從我的經驗來看，有很多代碼行（超過幾頁）的功能是維護和測試的噩夢。但是我說過，我認爲對此沒有硬性規定。

我在我以前的公司遇到過一些VB.NET代碼，其中一個函數是13頁，但是我的記錄是我剛剛拿到的一些VB6代碼，大約40頁！想象一下，試圖找出哪個如果陳述其他屬於當他們在屏幕上分開頁面。

Answer 9

我的（無可指責的）準則是一個屏幕的代碼。我看過有關頁面功能的代碼。這是催吐，是慈善。函數應該有一個單一的，重點的目的。如果你試圖做一些複雜的事情，請給一個「隊長」函數調用助手。

良好的模塊化使朋友和影響的人。

Answer 10

恕我直言，目標應該是最大限度地減少程序員必須同時分析代碼的數量，從而理解程序。一般來說，過長的方法會使代碼更難消化，因爲程序員必須一次查看大部分代碼。

另一方面，如果可以從調用它們的代碼中分別分析那些較小的部分，則將方法細分爲較小的部分將僅有幫助。將一種方法拆分成僅在被調用的環境中才有意義的子方法往往會損害而不是提高可讀性。即使在分割該方法之前已經有超過250行，將其分成十個單獨無意義的單獨分片將會簡單地將同時分析要求從250行增加到300+（取決於爲方法添加了多少行頭文件，調用它們的代碼等等）。在決定是否應該細分一個方法時，考慮這些片斷是否有意義，而不是考慮該方法是否「太長」更爲重要。一些20行程序可能會被分成兩行十行程序和一個調用它們的雙行程序而受益，但一些250行程序可能會受益於完全保持原樣。

另一點需要考慮，順便說一句，在某些情況下，程序所需的行爲可能不符合它所用語言的控制結構。大多數應用程序在行爲方面都有很大的「不關心」方面，並且通常可以分配與語言的可用控制結構很好匹配的行爲，但有時行爲要求可能無法在沒有笨拙代碼的情況下滿足。在一些這樣的情況下，將尷尬侷限於臃腫的單一方法，但是圍繞行爲要求構建的方法可能比將其分散在許多與整體行爲沒有明確關係的較小方法中更好。