Порядок предметів у класах: Поля, Властивості, Конструктори, Методи

Чи існує офіційна інструкція C # щодо порядку впорядкування елементів з точки зору структури класів?

Чи йде:

• Публічні поля
• Приватні поля
• Властивості
• Конструктори
• Методи
  ?

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

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

Якісь поради / пропозиції?

Відповідно до Документації Правил StyleCop замовлення здійснюється наступним чином.

У класі, структурі чи інтерфейсі: (SA1201 та SA1203)

• Постійні поля
• Поля
• Конструктори
• Фіналізатори (деструктори)
• Делегати
• Події
• Перелічує
• Інтерфейси ( реалізація інтерфейсу )
• Властивості
• Індексатори
• Методи
• Конструкції
• Заняття

У кожній з цих груп упорядковуйте доступ: (SA1202)

• громадські
• внутрішній
• захищений внутрішній
• захищені
• приватний

У кожній із груп доступу впорядковуйте статичні, а потім нестатичні: (SA1204)

• статичний
• нестатичний

У межах кожної із статичних / нестатичних груп полів впорядковуйте лише за допомогою читання, а потім не лише для читання: (SA1214 та SA1215)

• лише для читання
• нечитання

Список, який не розгортається, триває 130 рядків, тому я не буду його тут розгортати. Розгорнута частина методів:

• публічні статичні методи
• публічні методи
• внутрішні статичні методи
• внутрішні методи
• захищені внутрішні статичні методи
• захищені внутрішні методи
• захищені статичні методи
• захищені методи
• приватні статичні методи
• приватні методи

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

Замість групування за видимістю або за типом елемента (поле, властивість, метод тощо), як щодо групування за функціональністю?

Це старе, але все ще дуже актуальне питання, тому я додам це: що перше, що ви шукаєте, коли відкриєте файл класу, який ви можете чи не могли прочитати раніше? Поля? Властивості? З досвіду я зрозумів, що майже незмінно ходжу на полювання на конструкторів, бо найголовніше, що потрібно зрозуміти, - як цей об’єкт побудований.

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

Майбутня особливість первинного конструктора в C # 6 свідчить про те, що природне місце для конструктора знаходиться в самому верху класу - адже первинні конструктори задаються ще до відкритого дужки.

Смішно, скільки різниці має такий переупорядкування. Це нагадує мені про те, як usingвикористовувались замовлення операторів - спочатку з просторами імен системи. Команда "Організувати впорядкування" Visual Studio використовувала це замовлення. Тепер usings просто впорядковані в алфавітному порядку, без спеціального звернення до системних просторів імен. Результат просто відчуває себе простішим та чистішим.

Я не знаю про мову чи галузевий стандарт, але я схильний розміщувати речі в такому порядку з кожним розділом, загорнутим у #region:

використовуючи заяви

Простір імен

Клас

Приватні члени

Громадські властивості

Конструктори

Публічні методи

Приватні методи

Я рекомендую використовувати стандарти кодування від IDesign або ті, які вказані на веб-сайті Бреда Абрама . Це найкращі два, що я знайшов.

Бред сказав би ...

Учасники класів повинні бути за алфавітом і згруповані в розділи (Поля, Конструктори, Властивості, Події, Методи, Реалізація приватного інтерфейсу, Вкладені типи)

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

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Для мене це все одно має сенс

Від StyleCop

приватні поля, публічні поля, конструктори, властивості, публічні методи, приватні методи

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

Зазвичай я намагаюся слідувати наступній схемі:

• статичні члени (зазвичай мають інший контекст, повинні бути безпечними для потоків тощо)
• члени екземпляра

Кожна частина (статична та екземпляр) складається з таких типів членів:

• оператори (завжди статичні)
• поля (ініціалізовані перед конструкторами)
• конструктори
• деструктор ( традиція наслідувати конструкторів )
• властивості
• методи
• події

Потім члени сортуються за видимістю (від менш видимих ​​до більш видимих):

• приватний
• внутрішній
• внутрішньо захищений
• захищені
• громадські

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

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

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

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

Примітка. Я не використовую публічні чи захищені поля.

Найближчі, які ви, швидше за все, знайдете - "Правила дизайну, керований код та .NET Framework" ( http://blogs.msdn.com/brada/articles/361363.aspx ) Бреда Абрамса

Тут викладено багато стандартів. Відповідний розділ - 2,8, я думаю.

Єдині рекомендації щодо кодування, які я бачив для цього, - це розміщення полів у верхній частині визначення класу.

я схильний ставити конструктори поруч.

мій загальний коментар буде, що ви повинні дотримуватися одного класу на файл, і якщо клас достатньо великий, що організація властивостей проти методів викликає велике занепокоєння, наскільки великий клас і чи варто вам все-таки рефакторинг? це представляє численні проблеми?

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

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

Я тримаю це максимально просто (як мінімум для мене)

Перерахування
Декларації
Конструктори
Перекриває
Методи
Властивості
Обробник подій

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

Я знаю, що це старе, але моє замовлення таке:

в порядку публічного, захищеного, приватного, внутрішнього, абстрактного

• Константи
• Статичні змінні
• Поля
• Події
• Конструктор (и)
• Методи
• Властивості
• Делегати

Я також люблю виписувати такі властивості (замість скороченого підходу)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}