Должны ли перечисления в C # иметь свой собственный файл? [закрыто]

У меня есть класс, который использует перечисление, перечисление в настоящее время находится в своем собственном файле, который кажется расточительным.

Каково общее мнение о перечислениях, помещаемых в пространство имен файла, в котором они используются? Или перечисление должно действительно жить в своем собственном файле cs?

редактировать

Я должен упомянуть, что, хотя рассматриваемый класс использует эти перечисления, то же касается и внешних вызывающих. Другими словами, другой класс может установить эти перечисления. Таким образом, они не используются внутри класса, иначе этот вопрос не составит труда.

Я бы не сказал «расточительно» (сколько стоит дополнительный файл?), Но это часто неудобно. Обычно есть один класс, который наиболее тесно связан с enum, и я помещаю их в один файл.

Это действительно просто вопрос предпочтений.

Я предпочитаю помещать каждое перечисление в отдельный файл (аналогично для каждого интерфейса, класса и структуры, независимо от их размера). Их легче найти, когда я прихожу из другого решения или у меня нет ссылки на данный тип.

Размещение одного типа в каждом файле также облегчает выявление изменений в системах контроля версий без различий.

Это полностью вопрос стиля. Я склоняюсь к тому, чтобы Enums.csв решении был вызван файл, в котором собраны объявления enum.

Но они, как правило, обнаруживаются через F12ключ в любом случае.

Вопрос, который вы должны задать себе, был бы: есть ли что-нибудь о типе перечисления в C #, который указывает, что я должен относиться к нему иначе, чем все другие типы, которые я создаю?

Если перечисление является публичным, оно должно рассматриваться как любой другой публичный тип. Если это личное, объявите его как вложенный член класса, использующего его. Нет веской причины помещать два открытых типа в один файл просто потому, что один является перечислением. Тот факт, что это публичный тип, - все, что имеет значение; вкус типа нет.

Еще одним преимуществом размещения каждого типа (class, struct, enum) в своем собственном файле является управление исходным кодом. Вы можете легко получить всю историю типа.

Я размещаю в основном внутри пространства имен и вне класса, чтобы он был легко доступен другим классам в этом пространстве имен, как показано ниже.

namespace UserManagement
{
    public enum UserStatus { Active, InActive }
    class User
    {
        ...
    }
}

Обычно я предпочитаю, чтобы мои перечисления были в том же файле, что и класс, к которому они, скорее всего, будут принадлежать. Если, например, у меня есть класс, Taskперечисление TaskStatusбудет в том же файле.

Однако, если у меня есть перечисления более общего характера, я храню их в разных файлах.

Это зависит от того, какой доступ необходим.

Если перечисление используется только одним классом, можно объявить его в этом классе, потому что вам не нужно его использовать где-либо еще.

Для перечислений, используемых несколькими классами или в общедоступном API, я всегда буду хранить определение в своем собственном файле в соответствующем пространстве имен. Его гораздо проще найти, и стратегия следует шаблону «один объект на файл», который также хорошо подходит для классов и интерфейсов.

Я думаю, что это зависит от объема перечисления. Например, если перечисление относится к одному классу, например, используется, чтобы избежать сценария магической константы, то я бы сказал, поместите его в тот же файл, что и класс:

enum SearchType { Forward, Reverse }

Если перечисление является общим и может использоваться несколькими классами для различных сценариев, то я бы склонен использовать его в своем собственном файле. Например, приведенное ниже может быть использовано для нескольких целей:

enum Result { Success, Error }

Я склонен помещать перечисления в их собственный файл по очень простой причине: как и с классами и структурами, приятно точно знать , где искать, если вы хотите найти определение типа: в файле с тем же именем. (Если честно, в VS вы всегда можете использовать «Перейти к определению»).

Очевидно, это может выйти из-под контроля. Коллега, где я работаю, даже делает отдельные файлы для делегатов.

Одним из преимуществ использования отдельного файла для перечислений является то, что вы можете удалить исходный класс, который использовал перечисление, и написать новый класс, используя перечисление.

Если enum не зависит от исходного класса, то размещение его в отдельном файле облегчает будущие изменения.

Если вы используете надстройку USysWare File Browser для Visual Studio, вы можете очень быстро найти файлы с определенными именами в своем решении. Представьте себе, что вы ищете enum, который находится не в своем собственном файле, а вместо этого похоронен в каком-то файле в гигантском решении.

Для небольших решений это не имеет значения, но для больших становится все более важным хранить классы и перечисления в своих собственных файлах. Вы можете быстро найти их, редактировать их и многое другое. Я настоятельно рекомендую поместить ваше перечисление в отдельный файл.

И, как было сказано ... Насколько расточительным является файл, который в конечном итоге составляет всего пару килобайт?

Очень простое огромное преимущество для отдельного файла. Когда какой-либо объект находится в своем собственном файле MyObjectName.cs ... вы можете перейти в обозреватель решений и ввести MyObjectName.cs, и вам будет показан ровно 1 файл. Все, что делает отладку лучше, приятно.

Еще одно преимущество аналогичной заметки: если вы ищете все файлы ( ctrl+ shft+ F) по имени, вы можете найти 20 ссылок на имя в одном и том же файле ... и это найденное имя будет частью различных объектов. В окне Find Results все, что вы видите, это номер строки и имя файла. Вам придется открыть файл и прокрутить, чтобы выяснить, в каком объекте была найдена ссылка.

Все, что облегчает отладку, мне нравится.

Если у вас есть несколько проектов в одном решении. Тогда лучше создай еще один проект Utilities. Затем создайте папку \Enumerationsи создайте вложенную static class. А затем назначьте каждый статический класс, в котором вы будете создавать enum, который соответствует названию ваших проектов. Например, у вас есть проект с именем DatabaseReader и DatabaseUsers, тогда вы можете назвать статический класс как

public static class EnumUtility {
    #region --Database Readers Enum
    public static class EnumDBReader {
         public enum Actions { Create, Retrieve, Update, Delete}; 
    }
    #endregion

    #region --Database Users Enum
    public static class EnumDBUsers {
         public enum UserIdentity { user, admin }; 
    }
    #endregion

}

Тогда все перечисление, которое можно использовать во всех решениях по проектам, будет объявлено на нем. Используйте #, regionчтобы отделить каждую проблему. По этому легче искать любые перечисления

Мне нравится иметь один общедоступный файл перечислений с именем E, содержащий каждое отдельное перечисление, тогда любой enum может быть доступен с помощью E ... и они находятся в одном месте для управления.