Обязательное использование брекетов

Question

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

Пример:

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

// This is right.
if (foo) {
    // bar
} else {
    // baz
}
while (things) {
    // stuff
}

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

Итак, вопрос: есть ли веские причины, по которым это будет ошибочным или иным образом неразумным стандартом? Об этом было какое-то обсуждение, но никто не может предложить мне лучший контраргумент, чем «это ужасно».

Answer 1

Лучший аргумент противодействия, который я могу предложить, заключается в том, что дополнительные строки, занимаемые пробелом, уменьшают объем кода, который вы видите за один раз, а объем кода, который вы видите за один раз, является большим фактором в том, как легко обнаружить ошибки. Я согласен с причинами, которые вы указали для включения скобок, но за многие годы C ++ я могу вспомнить только один случай, когда я допустил ошибку в результате, и это было в месте, где у меня не было веских оснований пропускать скобки тем не мение. К сожалению, я не могу сказать вам, помогло ли когда-нибудь увидеть эти дополнительные строки кода на практике или нет.

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

Answer 2

Я применяю это до некоторой степени, с небольшими исключениями для операторов if, которые оценивают либо возврат, либо продолжение цикла

Итак, по моему стандарту это правильно:

if(true) continue;

Как это

if(true) return;

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

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

Answer 3

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

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

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

Две практики решают эту проблему лучше, выберите одну:

1) Закомментируйте if, while и т. Д. Перед однострочником с однострочником. То есть лечения

if(foo)
    bar();

как и любой другой многострочный оператор (например, назначение с несколькими строками или вызов функции с несколькими строками):

//if(foo)
//    bar();

2) Префикс // с ;:

if(foo)
;//    bar();

Если вы не поддерживаете одну строку, а отступы не отображаются на чужой машине ... у вас проблемы.

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

Напишите немного кода на Python. Это исправит, по крайней мере, некоторые вредные привычки отступов.

Кроме того, такие структуры, как } else {, для меня выглядят как нетакерская версия истребителя TIE.

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

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

int x = 0;
while(x < 10);
{
    printf("Count: %d\n", ++x);
}

Форсировка скобок не помогает найти ошибку в приведенном выше коде.

P.S. Я являюсь подписчиком школы «каждое правило должно говорить, почему», или, как сказал Далай-лама: «Знай правила, чтобы ты мог их нарушить».

Answer 4

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

Преимущества намного превышают любую "ужасную" причину, которую я слышал.

Существует стандарт кодирования, облегчающий чтение кода и уменьшающий количество ошибок.

Это один стандарт, который действительно окупается.

Answer 5

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

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

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

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

Answer 6

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

Answer 7

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

Answer 8

Мое личное правило: если это очень короткое «если», тогда поместите все это в одну строку:

if(!something) doSomethingElse();

Как правило, я использую это только тогда, когда есть несколько таких случаев подряд.

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

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

Answer 9

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

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

Итак, чтобы сделать стандарт кодирования:

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

• Посмотрите на альтернативы правилу - действительно ли это нужно? Если все ваши программисты хорошо используют пробелы (пустые строки и отступы), оператор if очень легко читается, и нет никакого способа, чтобы даже начинающий программист мог принять оператор внутри «if» за отдельный оператор. Если вы получаете много ошибок, связанных с if-scoping, основная причина, вероятно, в том, что у вас плохой стиль пробела / отступа, что делает код ненужным трудным для чтения.

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

• Соблюдайте самые эффективные правила и сбрасывайте мякину. Chaff - это, как минимум, любое правило, которое будет стоить вам дороже, чем любые ошибки, которые могут возникнуть при игнорировании правила. Но, вероятно, если у вас более 30 ключевых правил, ваши программисты проигнорируют многие из них, а ваши благие намерения будут как пыль.

• Запустить любого программиста, который комментирует случайные биты кода, не читая его: -)

P.S. Моя позиция в отношении бодрости такова: если оператор «if» или его содержание являются одной строкой, вы можете опустить скобки. Это означает, что если у вас есть if, содержащий однострочный комментарий и одну строку кода, содержимое занимает две строки, и поэтому требуются фигурные скобки. Если условие if занимает две строки (даже если содержимое представляет собой одну строку), то вам нужны фигурные скобки. Это означает, что вы опускаете фигурные скобки только в простых, простых и легко читаемых случаях, когда ошибки никогда не допускаются на практике. (Когда утверждение пустое, я не использую фигурные скобки, но я всегда помещаю комментарий, в котором четко указано, что оно пустое, и намеренно так. область должна быть пустой, а не зазвонил телефон, и вы забыли закончить код)

Answer 10

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

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

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

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