Все остальные ответы защищают правило вашего лектора 3.
Позвольте мне сказать, что я согласен с вами: правило избыточно, и я бы не стал его советовать. Это правда, что теоретически предотвращает ошибки, если вы всегда добавляете фигурные скобки. С другой стороны, Я никогда не сталкивался с этой проблемой в реальной жизни: вопреки тому, что подразумевают другие ответы, я ни разу не забыл добавить фигурные скобки, когда они стали необходимыми. Если вы используете правильный отступ, сразу становится очевидным, что вам нужно добавлять фигурные скобки, если отступы выполняются более чем в одном выражении.
Ответ «Компонента 10» фактически указывает на единственный возможный случай, когда это действительно могло привести к ошибке. Но, с другой стороны, замена кода регулярным выражением в любом случае требует огромной осторожности.
Теперь давайте посмотрим на другую сторону медали: есть ли недостаток в том, чтобы всегда использовать фигурные скобки? Другие ответы просто игнорируют этот момент. Но есть недостаток: он занимает много места на экране по вертикали, а это, в свою очередь, может сделать ваш код нечитаемым, потому что вам придется прокручивать больше, чем необходимо.
Рассмотрим функцию с большим количеством защитных предложений в начале (и да, это плохой код C ++, но на других языках это довольно распространенная ситуация):
void some_method(obj* a, obj* b)
{
if (a == nullptr)
{
throw null_ptr_error("a");
}
if (b == nullptr)
{
throw null_ptr_error("b");
}
if (a == b)
{
throw logic_error("Cannot do method on identical objects");
}
if (not a->precondition_met())
{
throw logic_error("Precondition for a not met");
}
a->do_something_with(b);
}
Это ужасный код, и я решительно утверждаю, что следующий код гораздо читабельнее:
void some_method(obj* a, obj* b)
{
if (a == nullptr)
throw null_ptr_error("a");
if (b == nullptr)
throw null_ptr_error("b");
if (a == b)
throw logic_error("Cannot do method on identical objects");
if (not a->precondition_met())
throw logic_error("Precondition for a not met");
a->do_something_with(b);
}
Точно так же короткие вложенные циклы выигрывают от отсутствия фигурных скобок:
matrix operator +(matrix const& a, matrix const& b) {
matrix c(a.w(), a.h());
for (auto i = 0; i < a.w(); ++i)
for (auto j = 0; j < a.h(); ++j)
c(i, j) = a(i, j) + b(i, j);
return c;
}
Сравнить с:
matrix operator +(matrix const& a, matrix const& b) {
matrix c(a.w(), a.h());
for (auto i = 0; i < a.w(); ++i)
{
for (auto j = 0; j < a.h(); ++j)
{
c(i, j) = a(i, j) + b(i, j);
}
}
return c;
}
Первый код краток; второй код раздут.
И да, это можно смягчить до некоторой степени, поставив открывающую скобку на предыдущую строку. Итак: если вы настаиваете на фигурных скобках, поставьте хотя бы открывающую скобку на предыдущую строку.
Вкратце: не пишите ненужный код, занимающий место на экране.
За время, прошедшее с момента написания ответа, я в основном принимал преобладающий стиль кода и использовал фигурные скобки, если только я не смог поместить весь отдельный оператор в предыдущую строку. Я по-прежнему утверждаю, что отсутствие избыточных фигурных скобок обычно более читабельно, и я все еще никогда не сталкивался с ошибкой, вызванной этим.
person
Konrad Rudolph
schedule
30.08.2012
5. Use unsigned for variables that are >= 0хороший трюк. Если вы уменьшаете unsigned int == 0, вы получите потерю значимости. Что легко может произойти. - person Pascal Lécuyot schedule 30.08.2012for (unsigned i = 100; i >= 0; --i). - person Archie schedule 30.08.2012(i % 2 == 0)противоречит (2). Вы полагаетесь на приоритет операторов, и смысл, конечно же,((i % 2) == 0), а не(i % (2 == 0)). Я бы классифицировал правило 2 как допустимое, но «всегда» неверно. - person Steve Jessop schedule 30.08.2012iне является переменной со значением ›= 0`. Это ›= 0 кроме, когда ожидается отрицательное значение для завершения цикла. Так что он не должен быть беззнаковым, и правило 5 не говорит, что оно должно быть беззнаковым :-) - person Steve Jessop schedule 30.08.2012i % 2 == 0требует скобок:(i % 2) == 0. И, конечно, если вы сделаете что-то вродеi = 2 * j + 1;, вам понадобится несколько круглых скобок:i = ((2 * j) + 1);. Ваш код в конечном итоге будет выглядеть как LISP (много адских глупых скобок. Не то, о чем вы спрашивали, но глупые правила приводят к глупому коду. Некоторые из этих рекомендаций представляют собой решения для кодирования ошибок новичков. Большинство программистов не остаются новичками для долго, и следовать правилам для начинающих - не лучшая идея. Научитесь писать правильный код. - person Pete Becker schedule 30.08.2012null_ptr- person thecoshman schedule 30.08.2012deleteв современном C ++. Вместо этого всегда используйте умные указатели. - person Neil G schedule 30.08.2012std::can<Worms>.open():) - person Component 10 schedule 30.08.2012if (condition) statement;в одной строке, что бывает редко. Так что я должен быть в основном в безопасности от вашего психотика, но не полностью. К сожалению, я поставил открывающую скобку на ту же строку, так что RMS все равно меня достанет. - person Steve Jessop schedule 30.08.2012for (int i = 0 ; 100 > i ; ++i)(согласно Правилу 4) ... - person TMN schedule 31.08.2012x + 5 * y == zгруппируются, возможно, вам стоит пройти курс алгебры, прежде чем заниматься программированием. - person Nate C-K schedule 02.09.2012((x + 5) * y) == z- person Izkata schedule 02.09.2012if (5 == myVar). Мне нравится Йода, но не это много. - person Laoujin schedule 02.09.2012macro... Хм! - person Emadpres schedule 05.09.2012=и==, но не настолько плохое, чтобы это оправдать. - person underscore_d schedule 21.04.2016