После сохранения большого количества кода, замусоренного #region (как на С#, так и на VB.NET), мне кажется, что эта конструкция - всего лишь куча "сделать работу" для программиста. Он работает, чтобы ПОТРЕБИТЬ вещи в код, а затем они очень сильно раздражают поиск и чтение кода.
Каковы преимущества? Почему кодеры идут на дополнительные проблемы, чтобы поместить это в свой код.
Сделай меня верующим!
A аналогичный вопрос уже задан.
но...
Я бы сказал больше не. Первоначально предполагалось скрыть сгенерированный код из WinForms в ранних версиях .NET. С частичными классами потребность, кажется, уходит. ИМХО теперь получает возможность злоупотреблять теперь как организационная конструкция и не имеет никакой компиляторной ценности. Все это для IDE.
Часто, как частичные, так и #области используются как костыль для плохого дизайна (например, класс слишком велик или пытается сделать слишком много вещей).
Лучшее использование, которое я использовал для #regions, - это группировка функциональности, которая видна во многих разных классах. Например, объекты ценности, имеющие геттеры, сеттеры, конструкторы и поддерживающие поля. Я бы очень хорошо сгруппировал эти идеи в регионы. Однако вопрос о том, делает ли код более чистым или труднее читать.
http://www.rauchy.net/regionerate/ - автоматически разбивается на область вашего кода;)
Я поклонник регионов для группировки разделов больших классов, скажем, все свойства вместе, все константы и т.д. Я - тот, кто постоянно разрушает код, который мне не нужно видеть в то время, поэтому я люблю регионы для этого.
Также я нахожу, что регионы действительно полезны при реализации интерфейсов, в частности нескольких интерфейсов. Я могу сгруппировать каждый интерфейс методов, свойств, событий и т.д., Чтобы было проще увидеть, какой метод принадлежит интерфейсу.
Я использую их все время. Опять же, как и все остальное, они могут быть использованы как для зла, так и для хорошего, и, безусловно, могут быть отличительной чертой плохого дизайна, но они могут быть использованы, чтобы помочь организовать код очень хорошо.
#region Properties
#region Update Section
#region Accessors
Конечно, вам следует избегать примера Джеффа
#Sweep under carpet
То, что я нахожу в них странным, как отметил Джефф, заключается в том, что они являются командой препроцессора компилятора для целей ui. Я уверен, что команда VS могла бы сделать что-то столь же полезное по-другому.
В наших бизнес-объектах есть регионы, и мы их любим.
Имеем:
У нас есть несколько других в зависимости от типа бизнес-объекта, с которым мы имеем дело (подписчик и т.д.)
Для многих классов регионы просто мешают - но для наших стандартных бизнес-объектов они сохраняют нам массу времени. Эти бизнес-объекты - это код gen'd, поэтому они очень последовательны. Можете добраться туда, где я хочу быть быстрее, чем беспорядок, если это не так, и последовательность позволяет легко находить друг друга.
Обычно я не использую области кода, за исключением одного конкретного свойства зависимости от случая. Несмотря на то, что свойства dependecy с удовольствием работают во многих отношениях, их декларации являются бельмом на глазу, и они быстро загромождают ваш код. (Как будто управление 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
Если у меня есть более одного свойства зависимостей, мне нравится начинать следующий #области на самой следующей строке. Таким образом, вы в конечном итоге со всеми из них сгруппированы в вашем классе, а код компактный и читаемый.
Кстати, если вы просто хотите заглянуть в объявление, наведите курсор мыши на него.
Следуя тому, что было сказано ранее Расселом Майерсом, если вы научитесь правильно реорганизовывать свой код (умение, которое разработчики должны изучить), на самом деле не так уж и много нужно для регионов.
Несколько недель назад я подумал, что регионы отличные, потому что они позволили мне скрыть мой жирный код, но после осуществления моих навыков кода я смог сделать его более тонким, и теперь я вписываюсь в класс размера 7 (кто-то должен ТАК делать что измерение для рефакторинга в будущем!: P)
Я нахожу, что они запутывают код во всех, кроме самого простого в использовании. Единственное, что мы предлагаем в наших проектах, - это те, которые IDE использует (реализация интерфейса и код дизайнера).
Правильные инструменты должны использоваться для правильной цели. Код должен быть написан, чтобы показывать намерение и функцию, а не произвольно группировать вещи. Организация вещей в группе модификаторов доступа или в какой-то другой группе просто кажется нелогичным. Я считаю, что код должен быть организован таким образом, который имеет смысл для конкретного класса; в конце концов, есть другие инструменты для просмотра членов класса с помощью модификатора доступа. Это также касается практически любого другого использования регионов; есть лучший способ.
Например, группировка свойств, событий, констант или иначе вместе не имеет смысла либо в том смысле, что код обычно более удобен в обслуживании, если вещи сгруппированы вместе функцией (как и в случае, свойство, которое использует константу, должно быть около постоянным, а не рядом с другими несвязанными свойствами только потому, что это свойство).
Есть моменты, когда ваши методы должны быть длинными, особенно с веб-разработкой. В таких случаях (например, когда у меня есть gridview с большим, сложным объектом, связанным с ним), я нашел полезным использовать регионы:
#region Declaring variables for fields and object properties
#region Getting the fields in scope
#region Getting the properties of the object
#region Setting Fields
Это дискретные разделы метода, которые МОГУТ быть разбиты, но это было бы сложно (мне пришлось бы использовать переменные с большей областью действия, чем мне нравится, или передавать LOT переменных как "out" ), и это основная сантехника.
В этом случае регионы вполне приемлемы. В других они бесполезны.
Я также буду использовать регионы для группировки методов в логические группы. Я отклоняю частичные классы для этой цели, поскольку у меня, как правило, много открытых страниц, когда я отлаживаю, и чем меньше частичных классов есть в объекте (или на странице или в диалоговом окне), тем больше у них может быть мой список вкладок (который я ограничиваю одной строкой, чтобы я мог видеть больше кода).
Регионы являются лишь проблемой при использовании в качестве костыля или когда они покрывают плохой код (например, если вы вложенные области внутри друг друга в пределах одного и того же объема, это плохой знак).
Я часто использую их вместо комментариев для упорядочения групп функций в теле класса, например. "Конфигурационный общий интерфейс", "Открытый публичный интерфейс", "Внутренняя обработка" и "Управление внутренними потоками".
Используя сочетания клавиш, чтобы "свернуть до определений" и "расширить текущий блок", я могу легко перемещаться по более крупным классам.
К сожалению, Регионы разбиты на С++, и MS не считает, что нужно исправлять.
Я ненавижу чрезмерное использование этих. Единственное, что я считаю полезным для них, это спрятать вещи, которые вы, вероятно, никогда не захотите увидеть снова. Опять же, эти вещи, вероятно, должны быть где-то в библиотеке.
Пожалуйста, просмотрите эту статью у Джеффа Этвуда по этому вопросу:
Их можно переоценить, но мне они нравятся для разделения частных методов, общедоступных методов, свойств и переменных экземпляра.
Как и любая особенность языка, регионы могут злоупотреблять и злоупотреблять, но также имеют свои преимущества.
Они отлично подходят для создания "складных" групп вокруг:
Вы также можете использовать его для группировки свойств, общедоступных/частных методов, событий, переменных класса и т.д.
Я использую регионы в своем коде, чтобы помочь создать согласованную структуру в моем коде, чтобы я всегда знал, где вещи с первого взгляда. Да, во время рефакторинга или добавления новых функций (особенно при автогенерации Visual Studio) это становится немного сложнее, но я чувствую, что это небольшая цена, чтобы поддерживать согласованность и структурирование.
Хорошие ответы, я согласен с ними в том, что они иногда отражают плохое кодирование и дизайн, но #region действительно полезен, если вы создаете документацию (стиль MSDN) с помощью SandCastle. Допустим, у вас есть открытый API, и есть некоторый базовый класс, для которого вы хотите привести пример использования. Затем вы должны правильно документировать свои общедоступные методы и добавить примерный регион, где вы могли бы скопировать и вставить код. Проблема заключается в том, что когда/если ваш базовый класс изменяется, вы должны в конечном итоге изменить пример. Лучшее решение состоит в том, чтобы включить проект образца кода в ваше решение и собрать его все вместе, поэтому каждый раз, когда вы создаете свое решение, если образец кода не обновляется, он не будет компилироваться. Так что же это касается регионов, к которым вы сейчас будете спрашивать себя. Посмотрите на этот образец:
/// <example>
/// The following code sample is an implementation of LoadPublishedVersion() for XmlPageProvider.
/// <code source="../CodeSamples/EPiServerNET/PageProvider/XmlPageProvider.cs" region="LoadPublishedVersion" lang="cs"/>
/// </example>
Обратите внимание, что есть ссылка на образец и регион исходного кода для метода, который вы хотите представить в качестве образца в своей документации. Посмотрите здесь результат. Этот метод должен быть в правильном регионе и будет автоматически включен в вашу документацию. Вот почему я еще не выбрал бы #region.
Я люблю регионы, потому что это помогает мне сосредоточиться только на том, над чем я работаю. Я использую их, даже если класс имеет только метод.
Я использую фрагменты кода с уже заполненными регионами, что меньше печатает. Я чувствую, что класс более организован и делает то, что говорит Code Complete, чтобы сделать его приятнее для других людей читать. Компилятор просто игнорирует их, теперь они должны сделать код более удобочитаемым.
На самом деле это не выгодно. Это запах кода. Некоторое время после их использования я устал от них. Если вам нужно разбить все по функциональности, используйте частичный класс.
Мой рабочий день начинается с открытия файлов в редакторе и нажатия "Развернуть все", чтобы скрыть все регионы. После этого я могу начать работать.