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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Класс

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

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

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

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

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

Ответ 6

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

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Мне все равно имеет смысл

Ответ 7

От StyleCop

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

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

Ответ 8

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

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

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

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

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

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

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

Ответ 9

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

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

Ответ 10

Мое предпочтение - упорядочить по типу, а затем уменьшать видимость следующим образом

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

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

Ответ 11

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

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

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

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

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

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

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

Ответ 16

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

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

Ответ 17

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

Ответ 18

The following table lists the kinds of members a class or struct may contain:

Member  Description

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

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

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

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

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

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

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

Финализаторы Финализаторы очень редко используются в С#. Это методы, которые вызываются механизмом исполнения во время выполнения, когда объект собирается удалить из памяти. Они обычно используются для обеспечения надлежащего обращения с любыми ресурсами, которые должны быть освобождены.

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