Порядок предметов в классах: поля, свойства, конструкторы, методы

Question

Есть ли официальное руководство по C # для заказа предметов с точки зрения структуры классов?

Идет ли:

• Публичные поля
• Личные поля
• Свойства
• Конструкторы
• Методы
  

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

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

Любые советы / предложения?

Answer 1

В соответствии с Документацией по правилам StyleCop порядок следующий:

Внутри класса, структуры или интерфейса: (SA1201 и SA1203)

• Постоянные поля
• Поля
• Конструкторы
• Финализаторы (деструкторы)
• Делегаты
• События
• Перечисления
• Интерфейсы ( реализации интерфейса )
• Свойства
• Индексаторы
• Методы
• 1032 * Структура *
• Классы

В каждой из этих групп порядок по доступу: (SA1202)

• общественное
• внутренний
• внутренняя защита
• 1046 * защищенный *
• частный

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

• статические
• нестатическая

Внутри каждой из статических / нестатических групп полей упорядочьте только для чтения, затем не только для чтения: (SA1214 и SA1215)

• 1062 * только для чтения *
• без * 1064 только для чтения *

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

• публичные статические методы
• публичные методы
• внутренние статические методы
• внутренние методы
• защищенные внутренние статические методы
• защищенные внутренние методы
• статические методы с защитой
• защищенные методы
• приватные статические методы
• частные методы

В документации отмечается, что если предписанный порядок не подходит, скажем, реализуется несколько интерфейсов, и методы и свойства интерфейса должны быть сгруппированы вместе, - тогда используйте частичный класс для группировки связанных методов и свойств вместе. 1091 *

Answer 2

Вместо группировки по видимости или по типу элемента (поле, свойство, метод и т. Д.), Как насчет группировки по функциональности?

Answer 3

Это старый, но все еще очень актуальный вопрос, поэтому я добавлю следующее: на что вы обращаете внимание в первую очередь, когда открываете файл класса, который вы могли или не могли прочитать раньше? Поля? Свойства? По своему опыту я понял, что почти всегда я иду на охоту за конструкторами, потому что самое основное, что нужно понять, это то, как строится этот объект.

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

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

Забавно, как много меняет такое изменение порядка. Это напоминает мне о том, как раньше упорядочивались операторы using - сначала с пространствами имен System. Команда Visual Studio «Упорядочить использование» использовала этот порядок. Теперь using просто упорядочены в алфавитном порядке, без особой обработки для пространств имен System. Результат выглядит проще и чище.

Answer 4

Я бы рекомендовал использовать стандарты кодирования от IDesign или те, что перечислены на сайте Брэда Абрама . Это лучшие два, которые я нашел.

Брэд сказал бы ...

Элемент класса должен быть в алфавитном порядке и сгруппирован в разделы (поля, конструкторы, свойства, события, методы, реализации частного интерфейса, вложенные типы)

Answer 5

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

с использованием выписок

Пространство имен

Класс

Личные участники

Публичная собственность

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

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

Частные методы

Answer 6

Как упоминалось ранее, в языке C # нет ничего, что определяло бы макет, я лично использую регионы и делаю что-то подобное для среднего класса.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Это все равно имеет смысл для меня

Answer 7

Обычно я стараюсь следовать следующей схеме:

• статические члены (обычно имеют другой контекст, должны быть поточно-ориентированными и т. Д.)
• члены экземпляра

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

• операторы (всегда статические)
• поля (инициализируются перед конструкторами)
• Конструкторы
• деструктор ( - это традиция следовать за конструкторами )
• Методы
• События

Затем элементы сортируются по видимости (от меньшего к более заметному):

• частный
• внутренний
• внутренняя защита
• 1038 * защищен *
• общественное

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

Answer 8

Из StyleCop

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

Поскольку StyleCop является частью процесса сборки MS, вы можете рассматривать это как стандарт де-факто

Answer 9

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

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, и если кто-то может дать мне вескую причину, почему я должен поместить детали реализации типа перед его интерфейсом, я готов изменить его. В настоящее время я твердо предпочитаю ставить частных членов в последнюю очередь.

Примечание: я не использую открытые или защищенные поля.

Answer 10

Ближайшее, что вы, вероятно, найдете, - «Рекомендации по проектированию, управляемый код и .NET Framework» (http://blogs.msdn.com/brada/articles/361363.aspx), автор Brad Abrams

Здесь изложены многие стандарты. Соответствующий раздел - 2,8, я думаю.