Как вы относитесь к сворачиванию кода?

Для тех из вас, кто работает в среде Visual Studio, как вы относитесь к обертке любого кода в #regions? (или если в любой другой IDE есть что-то подобное ...)

Ответов (24)

Решение

В 9 случаях из 10 сворачивание кода означает, что вы не смогли использовать принцип SoC как следует.
Я более или менее чувствую то же самое и с частичными классами. Если у вас есть фрагмент кода, который вы считаете слишком большим, вам нужно разделить его на управляемые (и многоразовые) части, а не скрывать или разделять.
Он укусит вас в следующий раз, когда кому-то понадобится его изменить, и не сможет увидеть логику, скрытую в 250-строчном монстре метода.

По возможности извлекайте код из основного класса во вспомогательный или фабричный класс.

foreach (var item in Items)
{
    //.. 100 lines of validation and data logic..
}

не так читается, как

foreach (var item in Items)
{
    if (ValidatorClass.Validate(item))
        RepositoryClass.Update(item);
}



В любом случае мои 0,02 доллара.

Часть этого Eclipse делает на Java (или PHP с плагинами) самостоятельно. Позволяет складывать функции и тому подобное. Мне это нравится. Если я знаю, что делает функция, и я не работаю над ней, мне не нужно на нее смотреть.

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

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

Есть отличный набор макросов VS.NET от Роланда Вайгельта, доступный в его записи в блоге « Лучшая поддержка клавиатуры для #region ... #endregion» . Пользуюсь ими годами, отображая ctrl +. чтобы свернуть текущую область и ctrl ++, чтобы развернуть ее. Выясните, что это работает намного лучше, чем функциональность VS.NET по умолчанию, которая все сворачивает / разворачивает.

Coding Horror статья фактической заставила меня думать об этом , а также.

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

Я лично ненавижу регионы. На мой взгляд, единственный код, который должен быть в регионах, - это сгенерированный код. Когда я открываю файл, я всегда начинаю с Ctrl + M + O. Это сводится к уровню метода. Когда у вас есть регионы, вы не видите ничего, кроме названий регионов.

Перед проверкой я логически группирую методы / поля, чтобы все выглядело нормально после Ctrl + M + O. Если вам нужны регионы, в вашем классе должно быть много строк. Я также считаю, что это очень часто.

регион ThisLooksLikeWellOrganizedCodeBecauseIUseRegions

// мусор полный, структуры здесь нет

конец области

Перечисления

Характеристики

.ctors

Методы

Обработчики событий

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

Звучит как ужасная идея :)

@ Том

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

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

Что касается других типов складывания, я все время складываю Functions. Если вы правильно назовете функцию, вам никогда не придется заглядывать внутрь, если вы что-то не тестируете или не пишете (переписываете).

Я лично постоянно использую #Regions. Я считаю, что это помогает мне хранить такие вещи, как свойства, объявления и т. Д., Отделенными друг от друга.

Это, наверное, тоже хороший ответ!

Кодирование ужасов

Изменить: Черт, Пэт победил меня в этом!

Я предпочитаю частичные классы, а не регионы.

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

Хотя я понимаю проблему, что Jeff, et. al. с регионами, я не понимаю, почему так сложно иметь дело с нажатием CTRL+ M, CTRL+, Lчтобы развернуть все регионы в файле.

Об этом говорили на Coding Horror .

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

Я использую его, чтобы упорядочить свои блоки кода в:
Перечисления,
Объявления,
Конструкторы,
Методы,
Обработчики событий,
Свойства.

Иногда вы можете работать в команде, где #regions поощряются или требуются. Если вы похожи на меня и терпеть не можете возиться со свернутым кодом, вы можете отключить структуру для C#:

  1. Параметры -> Текстовый редактор -> C# -> Вкладка Дополнительно
  2. Снимите флажок "Переходить в режим выделения при открытии файлов".

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

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

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

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

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

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

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

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

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

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

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

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

Сворачивание регионов было бы хорошо, если бы мне не приходилось вручную поддерживать группирование регионов на основе особенностей моего кода, которые присущи языку. Например, компилятор уже знает, что это конструктор. Модель кода IDE уже знает, что это конструктор. Но если я хочу увидеть представление кода, в котором конструкторы сгруппированы вместе, по какой-то причине я должен повторить тот факт, что эти объекты являются конструкторами, физически объединяя их вместе, а затем помещая вокруг них группу. То же самое касается любого другого способа разделения класса / структуры / интерфейса. Что, если я передумаю и хочу, чтобы общедоступные / защищенные / частные материалы сначала были разделены на группы, а затем сгруппированы по типу участников?

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

В любом случае, чтобы избежать использования регионов для этой цели, я написал бесплатную надстройку IDE для Visual Studio 2008 с открытым исходным кодом под названием Ora. Он автоматически предоставляет сгруппированный вид, что делает гораздо менее необходимым поддерживать физическую группировку или использовать регионы. Вы можете найти это полезным .

Обычно я обнаруживаю, что при работе с кодом, подобным Events в C#, где есть около 10 строк кода, которые на самом деле являются просто частью объявления события (класс EventArgs, объявление делегата и объявление события) Помещение области вокруг них, а затем их сворачивание кстати, делает его немного более читаемым.