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

Question

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

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#, но они не изолируют переменные.

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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(); 

Answer 6

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

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

просто написать:

if(n == 1) 
    i++; 

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

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