Семантическое использование # регион

Question

Каково ваше мнение об использовании #region Fold с использованием семантики приложения вместо свертывания для "синтаксиса".

Например:

#region Application Loop
#region User Management
#region This Kinf of stuffs

вместо

#region Private Routines
#region Public Properties
#region ThisRoutine // (Yes, I've seen this also!)

В этой логике я начинаю сбрасывать даже обычные тела. Я начинаю любить директиву #region (даже используя регион #pragma при использовании C ++!).

Answer 1

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

Обычно я использую регионы для реализаций интерфейса, переопределений Equals / GetHashCode и операторов - но обычно это все.

Answer 2

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

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

Я не фанат скрытия кода от себя.

Answer 3

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

Я бы сказал, пойти по схеме, которая очевидна.Наиболее распространенной является схема «Частные поля / Открытые поля / Частные свойства / Частные методы / Открытые свойства / Открытые методы».(Лично я предпочитаю группирование по видимости: «Public / Internal / Private» с более заметными членами наверху, поскольку именно это будет интересовать случайного посетителя класса в первую очередь, и то, что происходит, где все еще ослепительно очевидно.)

Answer 4

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

Таким образом, вместо публичных, защищенных, частных регионов, подумайте о «Инициализация», «Загрузка и сохранение», «Обработчики событий» и т. Д.

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

Answer 5

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