Как вы обычно размещаете регионы в классе?

Мне было интересно, существует ли стандарт для определения областей класса.

Я сейчас пользуюсь

Fields
Constructor
Properties
Public Methods
Private Methods

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

Связанные с классами Перечисления или иногда структуры / классы чистых данных (выше фактического определения класса)

--- определение класса ---

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

CTOR / DTOR, если в языке есть DTOR

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

Служебные методы (частные или защищенные методы с малой областью действия)

Функциональность класса (может быть разделена на несколько регионов в зависимости от области действия класса).

Субрегионы? Есть ли у вашего класса единственная ответственность ? (подразумевается, что ... мой ответ: "Редко любые регионы, за исключением, может быть, группирования свойств, конструкторов и методов" ... но даже тогда я не так часто его использую)

Я просто хотел подтвердить, что вы имели в виду "#regions", а не макет класса в целом.

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

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

Почему я ненавижу регионы? CTRL+M,Lи CTRL+M,Oпереключит сворачивание кода. Однако при обрушении он скрывает весь регион. Мне нужно только свернуть методы / свойства / комментарии.

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

Моя любимая цитата на # регионах:

Нет, я не буду использовать #regions. И нет, я не общаюсь с террористами. Молчи.

- Джефф Этвуд

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

Это зависит от языка к языку. Поскольку я программист Delphi, я склонен следовать стандартному соглашению Delphi, которое выглядит следующим образом:

type
  TMyClass = class(TBaseClass)
  private
    private fields
    private methods
  protected
    protected fields
    protected methods
    protected properties
  public
    constructor(s)
    destructor
    public methods
    public properties
  end;

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

Я склонен выкладывать их следующим образом:

Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields

Не использовался язык, который использует Properties, поэтому он не выложен. Я поместил закрытые методы и поля внизу, потому что, если кто-то еще использует этот файл в своем коде, им нужно только позаботиться о API, который является общедоступным. И все известные мне текстовые редакторы и даже IDE устанавливают курсор вверху при открытии файлов.

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

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

Пример использования #region: если я напишу тестовый метод для модульного теста, который требует многострочного фрагмента XML, строка XML нарушит обычные отступы (поскольку начинается с левого поля окно кода. Чтобы скрыть уродство, я оберну его в #region, чтобы я мог свернуть его.

В книге « Чистый код» Боба Мартина вся 5-я глава посвящена форматированию. Есть пара ключевых моментов, которые я чувствую, суммируя это красиво.

• Большинство попыток сгруппировать переменные и методы по видимости и чистоте. Не имеет большого смысла и заставляет вас много перемещаться по коду.
• Хранение методов, которые вызывают друг друга по вертикали, сокращает объем навигации, которая вам необходима, и облегчает поиск вещей.
• Ваш ход мыслей не будет нарушен, если вам придется остановиться и подумать "к какому региону относится этот фрагмент кода?" каждые несколько минут.
• Переменных экземпляра обычно должно быть немного, и они могут использоваться повсеместно, поэтому они принадлежат к верхней части класса, где их будет легче найти. Переменные и объявления, которые будут использоваться только одним методом, должны существовать внутри этого метода. Если они используются только несколькими методами, они должны быть расположены вертикально, но выше нескольких методов, которые их используют.

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

Если вам нужно «спрятать» код, потому что он слишком длинный или слишком «некрасивый», то у вас, вероятно, есть большие проблемы, о которых нужно беспокоиться, чем использование регионов. Лично мне никогда не нужно их использовать, и когда я работаю над чужим кодом, я всегда обнаруживаю, что мне всегда нужно их все открывать, так зачем беспокоиться?

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

class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables

а затем префикс уровня доступа к каждому объявлению (вроде, иногда группировать по доступу). Раньше я делал группировку верхнего уровня по доступу, но в какой-то момент я не знаю, когда, это не сработало так же хорошо, как и выше. Например, в C ++ / CLI (который я вынужден использовать в данный момент :-() вы можете сделать это, что испортит группирование по доступу:

public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}

Сумасшедший крайний ответ: я не знаю, по крайней мере, когда дело доходит до C #. Между Visual Studio и R # я могу волшебным образом перемещаться к любому члену или реализации, поэтому нет смысла зацикливаться на этом; просто начните вводить, где находится курсор.

Как и Уайетт и несколько других ответов, я также обычно избегаю использования регионов. Регионы имеют одну цель; чтобы скрыть код, на который вы не хотите смотреть. Если у вас в коде много кода, на который вам не нужно смотреть, и, следовательно, вам нужно много областей, чтобы можно было свернуть указанный код, то у вас, вероятно, слишком много кода в классе. ReSharper не учитывает регионы при выборе места для размещения нового кода, если только он не создал регион (что он делает для реализаций интерфейса).

Единственное использование регионов, которые я считаю приемлемыми, - это скрыть «неизбежно некрасивый» код; код, который имеет дело с конкретными деталями реализации, которые не могут быть внутренне хорошо спроектированы в соответствии с текущими стандартами. Обычно это продвинутый, эзотерический код, который обычно не следует путать со средним младшим программистом после его написания. Это такие вещи, как:

• Определенные реализации встроенного интерфейса (IDisposable, IConvertible, иногда IEnumerable или IComparable, поскольку они требуют универсальных и неуниверсальных реализаций)
• Встроенные P / Invoke внешние и связанные с ними структуры.
• Финализаторы / деструкторы (обычно идут с IDisposable)
• Перехватывает неуправляемую память / указатели / «небезопасный» код.