在單個文件中有多少代碼是多少？

Question

我在想今天人們通常在單個源文件中有多少代碼，然後才決定將其分割成多個較小的文件。

就我個人而言，我傾向於保持我的文件相當小（使用C/C++時，特別是頭文件）。這是我通常只會有一個類或一個給定的文件中的一堆功能，所以該文件一般是500行。然而，所有相關的東西通常共享相同的命名空間。

另一方面，我所使用的一些東西似乎非常高興地試圖儘可能地將其保存到單個文件中，這個文件長度爲1000年。

我更喜歡小文件，因爲任何更改只需要重新編譯一段代碼，並且我發現當它被分解爲每個具有特定用途的較小文件時更容易導航源代碼，而不是一個大型文件整個事情。幾個大文件有沒有真正的優勢？

例如我的粒子系統分解成system.h，emitter.h，load.h，particle.h等，並且對每個文件都有相應的.cpp文件。然而，一些粒子系統看起來似乎已將整個信號源整合到單個.h和.cpp 1000行的長度中。

Answer 1

小文件毫無疑問更容易閱讀和理解。但是，我不認爲你可以根據類或源文件中的行數來做出這個決定。如果您覺得應該將常用功能放在不同的文件中，請考慮分割您的代碼。它還可以更好地重用代碼。

Answer 2

您應該從邏輯上不物理地識別軟件模塊。 所以你應該根據責任來設計類/功能。

您可以使用CRC方法來確定每個班級的責任。

Answer 3

如果您不希望更改代碼，那麼對於用戶而言，一個巨大的單個文件可能會更方便。例如，SQLite將它們的代碼作爲單片源文件分發，用戶可以輕鬆地將它們合併到自己的版本中。

然而，在開發過程中，這是一個可怕的想法，因爲你提到的原因，也因爲它幾乎可以保證當多個程序員在項目中工作時會出現RCS合併問題。

Answer 4

我將項目的所有不同部分分成不同的文件，主要用於與其相關的編譯時間。當我需要鏈接的CC文件的對象已經存在時，我不必從頭開始重新編譯這些文件。

在單一文件或更小的文件之間做出決定應該是一個團隊決策，應該在團隊中的每個程序員都遵循的編碼規則中闡明，就像使用標籤/空間的準則一樣，應該有如何準則向項目添加新的代碼。

對於某些項目，將更多的代碼放在一起更合理，特別是如果僅使用項目的一個單獨部分而沒有其餘部分使得整個項目實際上無用。這是一個權衡，你必須衡量親和騙局，並最終你必須決定哪一個會更好地爲你工作。這就是說，許多較小的文件允許多個開發人員使用版本控制系統進行更簡單的開發，就像Perforce一樣，因爲它會進行更改，一個開發人員不太可能導致另一個開發人員在另一個開發人員工作時需要解決的提交問題的代碼。

Answer 5

這取決於當然，你不能限制自己的標準。但是，我在文章閱讀

你的方法應該是屏幕寬，所以你可以看到它發生了什麼不滾動，

參數到方法應小於或等於7，和你的產業深度應該小於或等於3，這對於人類毫無困難地理解是很好的。

在我看來，文件的限制應該是它的責任。每個文件都應該要求它自己的類，每個類都應該有一個責任。

Answer 6

在每個源文件中太少會有太多太糟糕 - 混亂只會從單個源文件移動到項目本身。

當我注意到源文件開始處理兩個（或更多）明確分離的方面時，我傾向於將其分開。

如果我有一種感覺，它包含的功能可能在將來會被很多修改，同時也具有可能穩定的功能，我也會將其分開。