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 в любом случае.

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

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

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

Мое личное убеждение в том, что они полезны, но, как и все остальное, может быть слишком много.

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

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

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

Код ужас

Редактировать: Данг, Пэт избил меня до этого!

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

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

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

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

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

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

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

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

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

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

@ Том

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

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

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

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

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

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

Роланд Вейгельт (Roland Weigelt) предлагает отличный набор макросов VS.NET, который можно найти в его записи в блоге, « Лучшая поддержка клавиатуры для #region ... #endregion» . Я использую их в течение многих лет, картируя Ctrl +. свернуть текущий регион и Ctrl ++, чтобы развернуть его. Выясните, что он работает намного лучше, чем стандартная функциональность VS.NET, которая складывает / раскладывает все.

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

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

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

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

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

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

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

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

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

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

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

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

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

регион ThisLooksLikeWellOrganizedCodeBecauseIUseRegions

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

endregion

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

свойства

.ctors

методы

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

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

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