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

17

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

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

Fields
Constructor
Properties
Public Methods
Private Methods

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

Рейчел
источник
1
Вы говорите о макете в целом или используете "#regions"?
snmcdonald
1
@snmcdonald Я использую #regionтеги, чтобы определить раздел
Рэйчел
Разве это не должно быть вопросом вики сообщества? Я не верю, что есть один стандарт, и ответ может меняться в зависимости от языков.
Raveline
7
Я начинаю с удаления всех #regions
Эд С.
3
@ Эд С. +1, потому что регионы дьявол. Все, что они позволяют вам сделать, это скрыть тот факт, что ваш файл кода слишком большой и нуждается в рефакторинге.
MattDavey

Ответы:

4

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

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

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

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

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

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

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

Пакс Ноктис
источник
17

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

MIA
источник
2
Я сейчас программирую в WPF, и примером некоторых субрегионов, которые я бы использовал, является ViewModel, чьи общие свойства разделены на свойства, связанные с пользовательским интерфейсом, Команды, Данные и т. Д. Это значительно упрощает поиск того, что я ищу быстро
Рейчел
2
Почему бы не использовать баннеры с большими комментариями вместо регионов? // ----------ViewModel Properties---------- Таким образом, вы все еще можете увидеть код (или свернуть его с выделением и увидеть членов). Регионы для сокрытия вещей. Код не должен быть скрыт, если он не создан автоматически или что-то в этом роде.
Kyralessa
1
@Рэйчел поддерживает композицию.
MattDavey
10

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

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

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

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

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

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

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

- Джефф Этвуд

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

snmcdonald
источник
1
Вот макрос, чтобы свернуть определения, но расширить регионы, если вы застряли, работая с людьми, влюбленными в регионы: stackoverflow.com/questions/523220/awesome-visual-studio-macros/… Он работает хорошо, если вы не работа с действительно больными людьми, которые помещают регионы в методы .
Kyralessa
Очень полезный макрос! Я не уверен, почему они не встроили это в визуальную студию, тем не менее, спасибо.
snmcdonald
Мой босс любит регионы, любит их. Он также любит частные внутренние занятия и огромные методы. В нашем коде есть один класс с примерно дюжиной областей, разделяющих его, 3 внутренних класса и несколько методов настолько длинных, что у них есть дюжина областей верхнего уровня, внутри которых находятся субрегионы.
CodexArcanum
4

Это зависит от языка к языку. Поскольку я программист 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;

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

Мейсон Уилер
источник
3
Я нахожу удивительным, что частные, защищенные, общедоступные и опубликованные упорядочены в алфавитном и инкапсуляционном порядке, и все они начинаются с P!
Питер Тернер
забавно, я не Я всегда обнаруживал, что publicсначала было удобнее перечислять , так как большинство пользователей заботятся только о publicвещах.
Матье М.
Я всегда считал эту конвенцию действительно глупой идеей. Какое отношение имеет видимость к функциональности? В любом случае я всегда использовал интерфейсы для определения общедоступных функций, но реализовал интерфейс как защищенный в классе. Единственными элементами, которые я буду последовательно группировать, являются методы и свойства Опубликованные для компонентов, а в остальном я всегда группирую по интерфейсам и наследованию, используя при необходимости несколько ключевых слов видимости. Те элементы, которые являются уникальными для реализации класса (т.е. не переопределяют), действительно должны быть перечислены первыми.
С.Робинс
3

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

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

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

gablin
источник
+1 за размещение приватных полей внизу. Я группирую открытые методы по интерфейсу, который они реализуют, и помещаю те, которые не реализуют какой-либо интерфейс, сверху, сразу после конструкторов / деструкторов.
Sjoerd
2

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

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


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

Роберт Харви
источник
2

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

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

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

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

S.Robins
источник
1
+1 - я удивлен, что это не было упомянуто более заметно. Принцип связности также применим к тому, как вы выкладываете свой код, а группировка по модификатору доступа (чаще всего) контрпродуктивна.
Даниэль Б
0

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

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 () { ... }
}
Skizz
источник
Что такое «члены» внизу? Для меня это универсальный термин для всех частей класса.
Мейсон Уилер
@Mason: должны быть «переменными-членами», чтобы избежать путаницы.
Skizz
Я действительно не могу группировать вещи по типу. Какая разница между методом и свойством на самом деле? Я никогда ни разу не искал свойства класса, однако я буду искать логически связанный код, будь то свойства, методы, что угодно.
Эд С.
0

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

Уайетт Барнетт
источник
0

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

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

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