我正在撰寫關於extremely long functions in the Linux kernel的學術項目。爲了這個目的，我正在尋找非常長（幾百行代碼）的實際功能的例子，你不認爲編程不好（即它們不會從分解或調度表的使用）。你寫了很長的函數嗎？如果是這樣，爲什麼？
你有沒有寫過或見過這樣的代碼？你能發佈或鏈接到它，並解釋它爲什麼這麼久？
我從這裏的社區獲得了驚人的幫助 - 任何將被納入該項目的想法都將得到正確評價。
感謝，
烏迪
我曾經寫的最長的功能都有一個共同點，非常大的switch語句。有時候，當你不得不打開很長的項目列表時，如果你試圖將某些選項重構成單獨的函數，它只會讓事情變得更難理解。擁有大量開關語句使得Cyclomatic的複雜性經歷了頂峯，但它通常比其他實現更好。
以前的工作：一個非常長的案例陳述，IIRC 1000+行。這是很久之前的對象。每個選項只有幾行。打破它會使它不太清楚。實際上有一對這樣的例程對相同的底層數據類型做不同的事情。
對不起，我沒有代碼了，反正它不是我的。
我可以想象，當速度很重要時（例如，在內核中持有某種鎖時），您不會因爲進行功能調用而導致功能中斷，編譯時，必須將參數壓入堆棧，並且在返回之前必須彈出數據。因此，出於效率的原因，您可能會有很大的功能。
我沒有看到可怕的最長函數將是自定義CPU虛擬機的關鍵方法。和@epotter一樣，這涉及到一個大的switch語句。事實上，我會說很多方法，我發現抗拒被幹淨地分解或改進可讀性涉及開關語句。
不幸的是，如果在構建步驟中使用某種代碼生成器自動生成，您將不會經常發現這種類型的子例程簽入或發佈到某處。
因此，尋找具有從其他語言生成的C的項目。
這是我被解僱前的最後一個。
除了性能，我認爲內核空間調用堆棧的大小是8K（請驗證大小）。另外，據我所知，內核代碼相當具體。如果某些代碼將來不太可能被重用，那麼爲什麼還要考慮函數調用的開銷，使它成爲一個函數。
您應該創建此社區wiki，因爲這是個人問題。 – Brandon 2009-07-17 16:26:03
他不會這樣做。他現在正在發佈模擬，這不太可能有助於他的研究項目。看到他的其他職位的證據。 – 2009-07-17 16:38:21