在一個文件中有多個類定義是不是很好的做法？

Question

在一個文件中有多個類定義是不是很好的做法？或者每個文件最好有一個類？

Answer 1

我更喜歡每個文件一個類。您永遠不必搜索正確的文件名，因爲它始終是類名稱。

Answer 2

我認爲這是最好有每個文件一個類，並組織他們在具有相同的層次結構，作爲命名空間的文件夾。

Answer 3

大多數程序員會認爲每個文件一個類是最佳實踐。

Answer 4

通常最好的做法是每個類有一個文件。

有些人，不是我喜歡有不止一個，如果他們是相關的，非常非常小的規模。其他人可能會在原型階段做到這一點。我說開始，留在每一個文件作爲他的重要著作Code Complete

引述確實斯科特·麥康奈爾在他的授課質量話語，「把一個類在一個文件中，文件是不只是持有桶一些代碼如果你的語言允許的話，一個文件應該包含一個只支持一個目的的例程集合，一個文件強化了一個例程集合在同一個類中的想法。

Answer 5

每個文件一個類。

這樣你可以避免合併編輯時，兩個人編輯同一個文件，因爲一個正在class A和其他正在class B。雖然這在任何源代碼控制系統中都應該是自動的，但這是一個額外的步驟，可能會被錯過，這會導致問題。

遠東最好是有一個過程，不允許擺在首位出現這種錯誤。

Answer 6

通常 - no。 以下練習「每個文件一個類」簡化了解決方案的瀏覽。 此外，如果您有一個使用悲觀方法（獨佔鎖）的開發人員和源代碼管理工具的大型團隊 - 開發人員在處理同一個文件時將遇到困難。

Answer 7

只要類是相互關聯的，我不會在同一個文件中看到多個類的問題。

如果你有resharper，你可以隨時使用導航工具找到任何類。

Answer 8

我會說不，我知道的DevExpress討厭它藏漢（它有一些不好的檢測practives）。

，但我有有時，當它的一個非常小的類多數民衆贊成basicly只能由文件中的「主」類中使用。 Personaly我認爲它有點味道，有一個10K行長的.cs文件或在你的項目中有許多.cs之間的平衡。

Answer 9

我想這是根據您的偏好。 我想你會發現大多數在線示例/大多數代碼是每個文件一個類，便於管理。

我有時會把2班在一個文件 - 只有當我使用的第二類作爲一個實體，它只是作爲一個在第一類中使用。

Answer 10

我認爲它是一種「最佳實踐」方法，那麼很可能是。但是，這實際上取決於項目。我傾向於將相關代碼放到獨立的單元，例如：

MyApplication.Interfaces 
MyApplication.Utils 
MyApplication.Controllers 

我真的覺得一個類只有永遠值得它自己的單位，如果它變得巨大。但是，如果它達到了這個階段，你應該開始考慮將一些代碼移入輔助類來分離邏輯。

Answer 11

我想你問，因爲你已經注意到，它被認爲是最佳實踐。鑑於顯而易見的好處（以及這裏提到的一些不那麼明顯的好處），爲什麼你想要以不同的方式做呢？每個文件在多個類中是否有任何好處？我想不出任何。

Answer 12

通常這是最好的解決方案，每個文件有一個類（文件的命名與包含的類完全相同）。

我只不同從，如果

• 有很多小枚舉 - >我收集這些成一個單一的文件如Enums.cs
• 有很多（20+）生成的類/接口彼此直接相關 - >將一個文件E.g. Interfaces.cs
• 有些東西不是應用程序的直接功能部分，而是緊密語義上的一致性（比如你需要的所有內容，通常是一些結構，枚舉，常量和一個類） - >以interop類命名的單個文件。
• 專用內部類 - >留在他們的父類，而不是局部類

Answer 13

我會用最就此達成一致。每個文件一個類是理想的。它可以讓您更輕鬆地查看項目中可用的內容，而無需依賴智能感知來發現給定程序集中可用的類型。

我認爲唯一一次我對每個文件規則中的一個類進行fudge的時候是我定義了一個自定義的EventArgs類，並且它與從另一個類中觸發的事件有關。然後，通常我會在同一個文件中將這些定義與該事件的委託一起定義。我不知道這是一種好的做法，還是出於純粹的懶惰？

Answer 14

如果您在一個非常大的項目上工作，太多的文件會顯着減慢構建時間（至少使用C++）。我不認爲嚴格遵守規則是必然的。

Answer 15

一類每個文件是我的首選方法，它可以幫助我擺脫任何混亂後來......我傾向於使用了很多，雖然部分類的......

Answer 16

只要我不打破1000線障礙，我會填入許多相關的類，這是有道理的。

有時抽象可能只是一個重寫的方法。