Действительно ли директива #region полезна в .NET?

Question

После поддержки большого количества кода, усеянного #region (как в C #, так и в VB.NET), мне кажется, что эта конструкция - всего лишь куча "make work" для программиста. Это работа для того, чтобы ЗАПИСАТЬ все эти чертовы вещи в код, а затем они делают поиск и чтение кода очень раздражающими.

Каковы преимущества? Почему кодеры идут на дополнительные хлопоты, чтобы вставить это в свой код.

Сделай меня верующим!

Answer 1

A аналогичный вопрос уже задан.

но ...

Я бы сказал больше нет . Первоначально он был предназначен для сокрытия сгенерированного кода от WinForms в ранних версиях .NET. С частичными уроками потребность, кажется, уходит. ИМХО, теперь он слишком часто используется как организационная структура и не имеет никакого значения для компилятора. Это все для IDE.

Answer 2

Часто и частичные, и #regions используются в качестве опоры для плохого дизайна (например, класс слишком большой или пытается сделать слишком много вещей).

лучшее использование, которое я когда-либо использовал для #regions, - это группировка функциональности, которая наблюдается во многих различных классах. Например, значения объектов, которые имеют геттеры, сеттеры, конструкторы и вспомогательные поля. Я вполне мог бы сгруппировать эти идеи в регионы. Однако вопрос в том, что делает код чище или труднее читать.

Answer 3

http://www.rauchy.net/regionerate/ - автоматически кодирует ваш код;)

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

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

Answer 4

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

#region Properties

#region Update Section

#region Accessors

Конечно, вы должны избегать примера Джеффа

#Sweep under carpet

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

Answer 5

У всех наших бизнес-объектов есть регионы, и мы их любим.

У нас есть;

• Бизнес свойства и методы
• Shared Methods
• Конструкторы
• Авторизация
• Доступ к данным
• События

У нас есть несколько других в зависимости от типа бизнес-объекта, с которым мы имеем дело (подписчик и т. Д.)

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

Answer 6

Обычно я не использую области кода, за исключением одного конкретного случая - свойств зависимости. Несмотря на то, что со свойствами зависимостей работать в большинстве случаев одно удовольствие, их объявления являются бельмом на глазу и быстро загромождают код (Как будто управление кодом GUI уже не было достаточно сложной задачей ...)

Мне нравится давать региону такое же точное имя, что и объявление свойства CLR (скопируйте / вставьте его туда). Таким образом, вы можете увидеть область действия, тип и имя, когда оно свернуто - это действительно все, что вас волнует в 95% случаев.

   #region public int ObjectDepthThreshold

    public int ObjectDepthThreshold
    {
        get { return (int)GetValue(ObjectDepthThresholdProperty); }
        set { SetValue(ObjectDepthThresholdProperty, value); }
    }

    public static readonly DependencyProperty ObjectDepthThresholdProperty = DependencyProperty.Register(
        "ObjectDepthThreshold",
        typeof(int),
        typeof(GotoXControls),
        new FrameworkPropertyMetadata((int)GotoXServiceState.OBJECT_DEPTH_THRESHOLD_DEFAULT,
            FrameworkPropertyMetadataOptions.AffectsRender,
            new PropertyChangedCallback(OnControlValueChanged)
        )
    );

    #endregion

Когда он рухнул, вы видите

public int ObjectDepthThreshold

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

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

Answer 7

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

Answer 8

Я часто использую их вместо комментариев , чтобы упорядочить группы функций в теле класса, например, «Конфигурация открытого интерфейса», «Статус открытого интерфейса», «Внутренняя обработка» и «Управление внутренними рабочими потоками».

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

К сожалению, регионы не работают на C ++, и MS не считает, что это нужно исправить.

Answer 9

Бывают случаи, когда ваши методы ДОЛЖНЫ быть длинными, особенно в веб-разработке. В тех случаях (например, когда у меня есть вид сетки с привязанным к нему большим сложным объектом), я считаю полезным использовать регионы:

#region Declaring variables for fields and object properties

#region Getting the fields in scope

#region Getting the properties of the object

#region Setting Fields

Это отдельные разделы метода, которые МОГУТ быть разбиты, но это будет трудно (мне придется использовать переменные с большей областью, чем мне нравится, или передать МНОГИЕ переменные как «out»), и это основная сантехника.

В этом случае регионы вполне приемлемы. В других они не нужны.

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

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

Answer 10

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

Нужные инструменты должны использоваться для правильной цели. Код должен быть написан, чтобы показать намерение и функцию, а не произвольно группировать вещи. Организовывать вещи в группы модификаторов доступа или в какую-то другую группу просто кажется нелогичным. Я считаю, что код должен быть организован таким образом, который имеет смысл для конкретного класса; В конце концов, есть другие инструменты для просмотра членов класса по модификатору доступа. Это также касается почти любого другого использования регионов; есть лучший способ.

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