Ответ 1

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


Всякий раз, когда вы можете, вытащите некоторый код из основного класса и в класс помощника или factory.

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

Ответ 2

Об этом говорилось в Coding Horror.

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

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

Ответ 3

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

• Параметры → Текстовый редактор → С# → вкладка "Дополнительно"
• Снимите флажок "Введите режим выделения при открытии файлов"

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

@Том

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

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

Ужас кодирования

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

Ответ 15

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

Ответ 16

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

Отличный набор макросов VS.NET от Roland Weigelt, доступный из его записи в блоге, Улучшенная поддержка клавиатуры для #region... #endregion. Я использую их в течение многих лет, сопоставляя ctrl+. для сглаживания текущей области и ctrl ++ для ее расширения. Найдите, что он работает намного лучше, чем функция VS.NET по умолчанию, которая складывает/разворачивает все.

Ответ 17

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

Ответ 18

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

Ответ 19

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

Ответ 20

Кодирование ужасов, статья также заставила меня задуматься об этом.

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

Ответ 21

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

Ответ 22

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

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

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

Ответ 23

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

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

region ThisLooksLikeWellOrganizedCodeBecauseIUseRegions

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

endregion

Ответ 24

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

Свойства

.ctors

Методы

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

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

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