Являются ли регионы областью антипаттерна или кода?

C # позволяет использовать ключевые слова #region /#endregion, чтобы сделать области кода разворачиваемыми в редакторе. Всякий раз, когда я это делаю, я делаю это, чтобы скрыть большие куски кода, которые, вероятно, могут быть реорганизованы в другие классы или методы. Например, я видел методы, которые содержат 500 строк кода с 3 или 4 регионами, чтобы сделать его управляемым.

Так разумно ли использование регионов признаком неприятностей? Мне кажется, это так.

215 голосов | спросил 2 revs, 2 users 67%
Craig
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

18 ответов


242

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

С

  

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

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

Не используйте регионы внутри методов; вместо этого refactor

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

Кроме того, каждый метод должен делать одно и только одно. . С другой стороны, регионы предназначены для разделения разных вещей . Если ваш метод делает A, то B, логично создать два региона, но это неправильный подход; вместо этого вы должны реорганизовать метод на два отдельных метода.

Использование регионов в этом случае также может затруднить рефакторинг. Представьте, что у вас есть:

private void DoSomething ()
{
    var data = LoadData ();
    #region Работа с базой данных
    var verification = VerifySomething ();
    если (! проверка)
    {
        throw new DataCorruptedException ();
    }

    У (данные);
    DoSomethingElse (данные);
    #endregion

    #region Audit
    var auditEngine = InitializeAuditEngine ();
    auditEngine.Submit (данные);
    #endregion
}

Свертывание первого региона, чтобы сосредоточиться на втором, не только рискованно: мы можем легко забыть об исключении, останавливающем поток (вместо этого может быть предложение охраны с return, что еще больше трудно обнаружить), но также будет иметь проблему, если код должен быть реорганизован следующим образом:

private void DoSomething ()
{
    var data = LoadData ();
    #region Работа с базой данных
    var verification = VerifySomething ();
    var info = DoSomethingElse (данные);

    если (проверка)
    {
        У (данные);
    }

    #endregion

    #region Audit
    var auditEngine = InitializeAuditEngine (info);
    auditEngine.Submit (
        проверка? new AcceptedDataAudit (данные): новый CorruptedDataAudit (данные));
    #endregion
}

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

Другой случай, который я иногда вижу, следующий:

public void DoSomething (строка a, int b)
{
    #region Проверка аргументов
    if (a == null)
    {
        throw new ArgumentNullException ("a");
    }

    если (b <= 0)
    {
        throw new ArgumentOutOfScopeException ("b", ...);
    }
    #endregion

    #region Сделайте настоящую работу
    ...
    #endregion
}

Заманчиво использовать регионы, когда проверка аргументов начинает охватывать десятки LOC, но есть лучший способ решить эту проблему: тот, который используется исходным кодом .NET Framework:

public void DoSomething (строка a, int b)
{
    if (a == null)
    {
        throw new ArgumentNullException ("a");
    }

    если (b <= 0)
    {
        throw new ArgumentOutOfScopeException ("b", ...);
    }

    InternalDoSomething (a, b);
}

private void InternalDoSomething (строка a, int b)
{
    ...
}

Не используйте регионы вне методов для группировки

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

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

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

Полезно ли использовать регионы?

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

Подумайте об этом как о goto. Тот факт, что язык или среда IDE поддерживает функцию, не означает, что она должна использоваться ежедневно. Правило StyleCop SA1124 ясно: вы не должны использовать регионы. Никогда.

Примеры

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

4 000 монстра LOC:

Недавно я прочитал где-то на Programmers.SE, что, когда файл содержит слишком много с помощью s (после выполнения команды «Удалить неиспользуемые команды»), это хороший признак того, что класс внутри этого файла делает слишком много. То же самое относится к размеру самого файла.

При просмотре кода я наткнулся на 4 000 файлов LOC. Оказалось, что автор этого кода просто копировал один и тот же метод с 15 строками сотни раз, слегка меняя имена переменных и вызываемый метод. Простое регулярное выражение позволило обрезать файл с 4 000 LOC до 500 LOC, просто добавив несколько дженериков; Я уверен, что с более умным рефакторингом этот класс может быть уменьшен до нескольких десятков строк.

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

Регион «До А», Регион «До B»:

Другим отличным примером был метод инициализации монстра, который просто выполнял задачу 1, затем задачу 2, затем задачу 3 и т. д. Было пять или шесть задач, которые были полностью независимыми, каждый из которых инициализировал что-то в классе контейнера. Все эти задачи были сгруппированы в один метод и сгруппированы в регионы.

Это имело одно преимущество:

  • Метод был довольно понятным, если посмотреть на названия регионов. При этом один и тот же метод после рефакторинга будет таким же ясным, как оригинал.

С другой стороны, проблемы были несколько:

  • Было не очевидно, существуют ли зависимости между регионами. Хотелось бы надеяться, что повторного использования переменных не было; в противном случае обслуживание может стать еще одним кошмаром.

  • Метод был почти невозможно проверить. Как бы вы могли легко узнать, правильно ли работает метод, который делает двадцать вещей за раз?

Область областей, область свойств, область конструктора:

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

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

Другая проблема заключается в том, что если вы это сделаете повсюду, вы обнаружите, что создаете одноблочные области, что не имеет никакого смысла. Это было на самом деле в коде, который я просмотрел, где было много #region Constructor, содержащего один конструктор.

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
90

Мне невероятно, сколько людей ненавидят регионы так страстно!

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

Но ни одна из этих вещей не означает, что существует что-то по своей природе неправильно с использованием регионов в вашем коде! Я могу только предположить, что большинство возражений людей исходят из того, что они работали над командами, в которых другие склонны неправильно использовать функции IDE, подобные этому. У меня есть роскошь работы с первичными, и я ценю, как регионы помогли организовать мой рабочий процесс. Может быть, это мое обсессивно-компульсивное расстройство, но мне не нравится видеть кучу кода на моем экране за раз, независимо от того, насколько аккуратно и элегантно написано это может быть. Разделение вещей в логические области позволяет мне свернуть код, который I не заботится о работе над кодом, который I делает . Я не игнорирую плохо написанный код, не имеет смысла реорганизовывать его больше, чем есть, а дополнительная организация «мета» описательна, а не бессмысленно.

Теперь, когда я больше времени работал на C ++, программируя более прямо в Windows API, я нахожусь в желании, чтобы поддержка регионов была такой же хорошей, как и для C #. Вы можете утверждать, что использование альтернативной библиотеки графического интерфейса сделает мой код более простым или понятным, что избавит вас от ненужного шума на экране, но у меня есть другие причины не желать этого. Я достаточно хорошо разбираюсь в своей клавиатуре и IDE, что расширение /сворачивание кода, разделенного на регионы, занимает менее одной секунды. Время, которое я сохраняю в мозге, пытаясь ограничить мое сознательное внимание только коду, над которым я сейчас работаю, более чем того стоит. Все это принадлежит одному классу /файлу, но в то же время он не все принадлежит моему экрану.

Дело в том, что использование #regions для разделения и логического разделения вашего кода - это не плохо, чего следует избегать любой ценой. Как указывает Эд, это не «запах кода». Если ваш код пахнет, вы можете быть уверены, что он поступает не из регионов, а из любого кода, который вы пытались похоронить в этих регионах. Если функция помогает вам быть более организованной или писать лучший код, то я говорю использовать ее . Если это становится помехой или вы неправильно используете его, используйте остановить . Если худшее приходит к худшему, и вы вынуждены работать в команде с людьми, которые его используют, а затем запомните комбинацию клавиш, чтобы отключить код: Ctrl + M , Ctrl + P . И перестаньте жаловаться. Иногда я чувствую, что это еще один способ, что те, кто хочет, чтобы их рассматривали как «истинных», «хардкорных» программистов, хотели попробовать и проявить себя. Вы не лучше избегаете регионов, чем избегаете синтаксической раскраски. Это не делает вас более профессиональным разработчиком.

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
59

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

Мне лично не нравится использовать много регионов. Это затрудняет получение кода, и код - это то, что меня интересует. Мне нравятся регионы, когда у меня есть большой кусок кода, который не нужно часто затрагивать. Кроме того, они просто мешают мне, и такие регионы, как «Частные методы», «Общественные методы» и т. Д., Просто сводят меня с ума. Они сродни комментариям сорта i ++ //increment i.

Я бы также добавил, что использование регионов не может быть «анти-шаблоном», поскольку этот термин обычно используется для описания программных логических /дизайнерских шаблонов, а не для макета текстового редактора. Это субъективно; используйте то, что работает для вас. Вы никогда не закончите с невыполнимой программой из-за чрезмерного использования регионов, и это все, что касается анти-шаблонов. :)

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
20

Да, регионы - запах кода!

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

Можете ли вы придумать один пример, в котором вы, хотя «гоните, я хочу, чтобы мой коллега использовал здесь некоторые регионы!»

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

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

Бесценный уход!

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
11

Я лично использую регионы как способ группировать различные типы методов или части кода вместе.

Таким образом, файл кода может выглядеть следующим образом:

  • Открытые свойства
  • Конструкторы
  • Сохранить методы
  • Изменить методы
  • Частные методы помощи

Я не помещаю регионы внутри методов. ИМХО, что является признаком запаха кода. Однажды я наткнулся на метод длиной более 1200 строк и имел в нем 5 разных регионов. Это было страшное зрелище!

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
10

Использование блоков #region для чтения очень большого класса обычно является признаком нарушения принципа единой ответственности. Если они используются для группировки поведения, то также возможно Вероятно , что класс делает слишком много (снова нарушая SRP).

Придерживаясь строки мысли «код запаха», блоки #region не являются кодовыми запахами и сами по себе, но вместо этого они больше «Febreze for code» в том смысле, что они пытаются скрыть запахи. Хотя я использовал их в прошлом, когда вы начинаете рефакторинг, вы начинаете видеть меньше, потому что они в конечном итоге не скрывают много.

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
4

Мое правило: Если в файле имеется более 5 регионов, это запах кода

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

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
4

Ключевое слово здесь - «разумное». Трудно представить себе случай, когда помещение области внутри метода разумно; это, скорее всего, будет скрывать код и лень. Однако могут быть веские причины иметь несколько регионов здесь и там в своем коде.

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

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

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

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
4

РЕГИОНЫ ИМЕЮТ ИХ ИСПОЛЬЗОВАНИЕ

Я использовал их лично для событий интерфейса «hand coding» раньше для приложений форм Windows.

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

Поэтому, хотя я не часто их использую, они отлично подходят для удаления больших кусков кода.

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
4

Если у вас есть регионы IN , у вас наверняка есть проблема (запрет на сгенерированный код). Ввод областей в код в основном говорит «рефакторинг».

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
3

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

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

По моему опыту, метод с сотнями строк кода определенно является запахом.

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
3

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

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
3

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

Я могу грубо разделить код использования региона, который я видел на сегодняшний день, в три категории:

  • Плохо оформленный код: Большая часть кода, который я видел, использует регионы как инструмент факторинга бедного человека. Например, класс, который вырос до такой степени, что имеет смысл специализировать его для разных целей, может быть разделен на отдельные области, по одному для каждой цели.

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

  • Код, написанный студентами или недавними выпускниками. Некоторые программы и курсы, похоже, пытаются внедрить студентов с использованием регионов во всевозможные странные цели. Вы увидите регионы, засоряющие исходный код, до точки, где отношение тегов региона к строкам кода находится в диапазоне от 1: 5 или хуже.

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
3

Я бы сказал, что это «запах кода».

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
3

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

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

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
2

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

В этом плагине максимальный размер шрифта для регионов очень мал. Они также будут расширены, поэтому вам не придется нажимать ctr + m + l, чтобы открыть все регионы. Он не фиксирует эту форму рака кода, но делает ее терпимой.

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
0

Регионы представляют собой препроцессорные выражения - другими словами, они обрабатываются как комментарии и в основном игнорируются компилятором. Это просто визуальный инструмент, используемый в Visual Studio. Поэтому #region на самом деле не является запахом кода, потому что это просто не код. Запах кода скорее представляет собой метод 800 строк, который имеет множество разных обязанностей, встроенных в и т. Д. Поэтому, если вы видите 10 регионов в одном методе - вероятно, это используется, чтобы скрыть запах кода. Сказав, что я видел, что они использовали чрезвычайно эффективно, чтобы сделать класс более приятным для глаз и более доступным для навигации - в очень хорошо написанном и структурированном классе!

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31
-1

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

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

#region "private_static_members"
 ///<summary>
 ///кэш для LauncherProxy
 ///</summary>
private static LauncherProxy _launcherProxy;
#endregion

#region "protected_const_properties"
защищенный LauncherProxy LauncherProxy {
  получить{
    if (_launcherProxy == null) {
      if (! God.Iam.HasProxy (LauncherProxy.NAME)) {
        God.Iam.RegisterProxy (новый LauncherProxy ());
      }
      _launcherProxy = God.Iam.Proxy (LauncherProxy.NAME) как LauncherProxy;
    }
    return _launcherProxy;
  }
}
#endregion

в код и каждая деталь аккуратно заправлена ​​в соответствующую область.

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

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

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

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

ответил Bernard 12 J000000Tuesday11 2011, 23:13:31

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132