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

Question

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

public void doSomething(){
    // common variables needed by all blocks

    { // comment for block 1
        ...
        ... about 5 to 30 lines of code
        ...
    }

    { // comment for block 2
        ...
        ... about 5 to 30 lines of code
        ...
    }

}

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

Вы бы сказали, что это плохая практика?Многие люди, которых я закодировал, не согласны с этим стилем кодирования.Я знаю, что в c # есть области, но они не изолируют переменные.

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

Answer 1

Если вы можете так разбить код, почему бы просто не разбить его на отдельные методы?Затем измените ваш doSomething() метод на просто , вызывающий эти меньшие методы?

Таким образом:

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

if(n == 1)
{
   i++;
}

просто напишите:

if(n == 1)
   i++;

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

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

Answer 6

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

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

glBegin(GL_TRIANGLES); {
    glVertex3f( 0.0f, 1.0f, 0.0f);
    glVertex3f(-1.0f,-1.0f, 0.0f);
    glVertex3f( 1.0f,-1.0f, 0.0f);
}; glEnd();