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

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

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

Брэд говорил...

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

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

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

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

забавно, насколько большая разница в переупорядочении, как это делает. Это напоминает мне о том, как using операторы, используемые для упорядочения - с помощью Пространства имен системы. Команда Visual Studio "Organize Usings" использовала этот порядок. Сейчас usings просто упорядочены в алфавитном порядке, без специального обращения к системным пространствам имен. Результат просто чувствует себя проще и чище.

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

с помощью операторов

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

класс

частные члены

свойства

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

методы

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

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

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

это имеет смысл для меня в любом случае

От StyleCop

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

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

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

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

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

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

затем члены сортируются по видимости (от менее до более видимых):

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

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

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

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

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

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

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

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

единственные рекомендации по кодированию, которые я видел, предложили для этого, чтобы поместить поля в верхней части определения класса.

Я склонен ставить конструкторы рядом.

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

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

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

Я держу его как можно проще (для меня, по крайней мере)

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

там, конечно, нет ничего в языке, который принуждает его в любом случае. Я склонен группировать вещи по видимости (public, затем protected, затем private) и использовать #regions для функционального группирования связанных вещей, независимо от того, является ли это свойством, методом или чем-то еще. Методы построения (будь то фактические ctors или статические заводские функции) обычно находятся на самом верху, так как они являются первым, что клиенты должны знать.

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

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

• константы
• Статические Переменные
• поля
• событий
• конструктор(ы)
• методы
• свойства
• представители

мне также нравится выписывать такие свойства (вместо стенографического подхода)

// 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; }
}