在決定應該在哪裏定義枚舉和結構時，什麼是好的做法？

Question

假設enum或struct沒有嵌套在一個特定的類，即它屬於項目命名空間內，它應該在被定義爲：

• 它自己的文件
• 通用文件名爲Enums.cs或Structs.cs在所有的enums/structs屬於該項目命名空間將被定義
• 別的地方...

Answer 1

This MSDN article on enum best practices不建議在哪裏存儲枚舉定義。

你會得到不同的建議。就我個人而言，我傾向於將枚舉存儲在與其相關的類相同的文件中。我希望儘可能使我的文件結構與我的命名空間結構保持一致，因此如果我的枚舉自然落入特定的命名空間，我會將該定義存儲在相應的文件中。

我的建議是，找一個適合你的方案，並堅持下去。

Answer 2

個人而言，我更喜歡一種類型，一種文件哲學。我甚至在嵌套類型的單獨文件中使用了部分類來允許分離。

我主要這樣做是因爲我看到了太多相反的東西。包含數十個類的單個文件。經歷改變了我。

Answer 3

對我來說，一種類型=一個文件，除非它是一個委託。由於Func和Action，我現在不需要經常聲明自己的代表，但是當我這樣做時，我發現有一個Delegates.cs文件是有用的。

至於結構 - 我只能記得寫關於其中兩個，除了爲了測試結構可以做的mutable這些壞事情。但我也會堅持每個文件一個。你爲什麼不呢？僅僅因爲它們是值類型並不意味着它們自然比類更短或更簡單。 （你能想象如果decimal和DateTime都在同一個源文件？Eek！）

編輯：我剛剛想過另一種情況，其中有多個結構可能是適當的：互操作。在這種情況下，我可能會有Interop.cs或Win32.cs ...或者可能有一個命名空間，並返回到每種類型的一個文件。

Answer 4

我把我所有的枚舉放在他們自己的文件中。但是，我也完全xml doccomment所有我的類型，包括枚舉...所以我的枚舉文件中可能有更多的代碼行比大多數人。我沒有寫很多年的結構，但我不認爲它們比任何一個類都少（再次，我完全xml doccomment包括我的所有類型，結構），所以他們在過去總是有自己的文件。

當涉及到代表，因爲它們通常是一個襯墊（減去doccomment），所以我傾向於將它們保留在相同的文件中，而不管它們支持哪種更突出的類型。這些天我不經常寫代表，但有時我發現他們仍然有用。不過，我會盡量讓任何代表在文件頂部聲明，而不是嵌套或低於主類型......讓他們更容易找到它們。

我認爲還有一個非常簡單但實際的理由，讓每個類型都保存在自己的文件中。他們很容易找到這種方式。如果您將枚舉和結構埋入其他類型中，或將它們保存在另一個文件中，有時（並不假設您，以及讀取您的代碼的人員始終訪問Visual Studio及其所有豐富的工具），它可以是很難找到你想要的類型。