Чи повинні переписки у C # мати власний файл? [зачинено]

У мене клас, який використовує перерахування, перелік наразі є у власному файлі, який здається марним.

Яка загальна думка щодо розміщення переліків у просторі імен файлу, в якому вони вживаються? Чи повинен переслідувати дійсно власний файл cs?

Редагувати

Я мушу зазначити, що, хоча відповідний клас використовує ці перерахування, це робить і зовнішні дзвінки. Іншими словами, інший клас може встановити ці перерахування. Таким чином, вони не використовуються всередині класу, інакше це запитання не може спричинити.

Я б не сказав "марнотратний" (скільки коштує додатковий файл?), Але це часто неприємно. Зазвичай є один клас, який найбільше асоціюється з перерахунком, і я поміщую їх у один і той же файл.

Це справді лише питання переваги.

Я вважаю за краще кожне перерахування розмістити у власному файлі (так само для кожного інтерфейсу, класу та структури, незалежно від того, наскільки мало). Це полегшує їх пошук, коли я виходжу з іншого рішення або в іншому випадку вже не мають посилання на відповідний тип.

Введення одного типу у кожен файл також полегшує ідентифікацію змін у системах управління джерелами, не змінюючи їх.

Це цілком питання стилю. Те, що я схильний робити, - це файл, який називається Enums.csв рішенні, в якому збираються декларації перерахунків.

Але вони, як правило, знаходяться через F12ключ все одно.

Питання, яке слід задати собі, було б: чи є щось про тип перерахування в C #, що вказує на те, що я повинен ставитися до нього по-різному від усіх інших типів, які я створюю?

Якщо перерахування є загальнодоступним, до нього слід ставитися як до будь-якого іншого публічного типу. Якщо він приватний, оголосьте його як вкладений член класу, використовуючи його. Немає вагомих причин розміщувати два загальнодоступні типи в одному файлі просто тому, що один є перерахуванням. Те, що це публічний тип - це все, що має значення; аромат типу не має.

Ще одна перевага розміщення кожного типу (клас, структура, enum) у власному файлі - це управління джерелами. Ви можете легко отримати всю історію типу.

Я розміщую всередині всередині простору імен і поза класом, щоб було легко доступними інші класи в цьому просторі імен, як нижче.

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

Як правило, я вважаю за краще, щоб мої переліки були у тому ж файлі, що і клас, до якого, швидше за все, це буде атрибут. Якщо, наприклад, у мене є клас, Taskто enum TaskStatusбуде в одному файлі.

Однак якщо у мене є переліки більш загального характеру, то я зберігаю їх контекстуально у різних файлах.

Це залежить від того, який доступ потрібен.

Якщо enum використовується лише одним класом, то добре оголосити його в межах цього класу, тому що вам не потрібно використовувати його більше ніде.

Для переліків, які використовуються у декількох класах або у відкритому API, я завжди зберігатиму визначення у власному файлі у відповідному просторі імен. Це набагато простіше знайти такий спосіб, і стратегія слідує шаблону один об'єкт на файл, який також добре використовувати з класами та інтерфейсами.

Я думаю, що це залежить від обсягу перерахунку. Наприклад, якщо enum є специфічним для одного класу, наприклад, використовується для уникнення магічного константного сценарію, я б сказав, покладіть його в той самий файл, що і клас:

enum SearchType { Forward, Reverse }

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

enum Result { Success, Error }

Я схильний містити переписки у власному файлі з дуже простої причини: як і у класах і структурах, приємно точно знати , де шукати, якщо ви хочете знайти визначення типу: у однойменному файлі. (Для справедливості, у VS ви завжди можете також використовувати "Перейти до визначення".)

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

Однією з переваг використання окремого файлу для переліків є те, що ви можете видалити початковий клас, який використовував enum, і написати новий клас за допомогою enum.

Якщо enum не залежить від початкового класу, то розміщення його в окремому файлі спрощує майбутні зміни.

Якщо ви використовуєте надбудову файлового браузера USysWare для Visual Studio, ви можете дуже швидко знайти файли конкретних імен у своєму рішенні. Уявіть, що ви шукаєте перерахунку, який знаходиться не у власному файлі, а замість цього закопаний у якийсь файл у гігантському рішенні.

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

І як було зазначено ... Наскільки марнотратним є файл, який у будь-якому разі становить лише пару кілоб?

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

Ще одна перевага подібної примітки, якщо ви шукаєте ім’я у всіх файлах ( ctrl+ shft+ F), ви можете знайти 20 посилань на це ім’я в одному файлі ... і це знайдене ім’я буде частиною різних об'єктів. У вікні "Результати пошуку" ви можете побачити лише номер рядка та ім'я файлу. Вам потрібно було б відкрити файл і прокрутити, щоб з’ясувати, в якому об’єкті було знайдено посилання.

Мені подобається все, що полегшує налагодження.

Якщо у вас є кілька проектів за одне рішення. Тоді краще створити ще один проект Utilities. Потім створіть папку \Enumerationsта створіть вкладені static class. А потім призначте кожному статичному класу, де ви будете створювати перелік, який відповідає імені ваших проектів. Наприклад, у вас є проект з назвою 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щоб розділити кожну проблему. Цим легше шукати будь-які перерахунки

Мені подобається мати один загальнодоступний файл enums з назвою E, що містить кожен окремий перелік, то будь-який перелік може бути доступний за допомогою E ... і вони знаходяться в одному місці для управління.