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

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

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

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

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

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

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

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

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

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

с помощью выражений

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

Класс

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

Публичные свойства

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

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

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

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

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

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

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

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

Здесь указаны многие стандарты. Соответствующий раздел - 2.8. Думаю.

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

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

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

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

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

Это полностью зависит от вас. Вы должны согласиться с некоторыми стандартами. даже плохой стандарт. Но лучше следовать хорошему стандарту:)

Я стараюсь как можно проще (по крайней мере для меня)

Перечисление
Объявления
Конструкторы
Заменяет
Методы изображения Свойства
Обработчик событий

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

Я не считаю необходимым навязывать определенный стиль или порядок в классе.

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