Действительно ли это - плохая практика для использования оператора "if" без фигурных скобок? [закрытый]

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

if(statement)
{
    do this;
}
else
{
    do this;
}

Однако, я думаю, что лучшее решение Эта проблема в Python. С помощью структуры блока на основе пробелов у вас нет двух разных методов создания оператора IF: у вас есть только один:

if statement:
    do this
else:
    do this

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

Используйте брекеты для всех, если утверждения даже простые. Или переписать простое, если оператор использует оператор Ternary:

if (someFlag) {
 someVar= 'someVal1';
} else {
 someVar= 'someVal2';
}

выглядит намного приятнее:

someVar= someFlag ? 'someVal1' : 'someVal2';

:

someVar= someFlag ? 'someVal1' : 'someVal2';

, но только используйте The Ternary Operator, если вы абсолютно уверены, что нет ничего, что нужно идти в блоках IF / Evel!

Мой общий шаблон заключается в том, что если он подходит для одной строки, я сделаю:

if(true) do_something();

, если есть пункт остального, или если код, который я хочу выполнить true имеет значительную длину Брекеты полностью:

if(true) {
    do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}

if(false) {
    do_something();
} else {
    do_something_else();
}

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

Наличие брекетов прямо с первого момента, должно помочь вам, чтобы вы когда-либо были отладки этого:

if (statement)
     do this;
else
     do this;
     do that;

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

if( statement ) {

    // let's do this

} else {

    // well that sucks

}

Я думаю, что это выглядит чисто и делает мой код очень легко читать и главное - отладка.

Из моего опыта только (очень) незначительное преимущество первой формы является чёркость кода, вторая форма добавляет «шум».

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

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

Одно из самых важных правил, чтобы помнить, когда запись кода является согласованностью. Каждая строка кода должна быть написана так же, независимо от того, кто его написал. Быть строгими мешает ошибками «происходит»;)

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

, когда мои студенты принимают этот факт, они перестают бороться с Их собственный Sourcecodode, и они начинают видеть кодировку как действительно интересную, стимулирующую и творческую деятельность. Они оспаривают свои умы, а не на нервы!

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

Добавить SETVBUF Вызовы перед первым Scanf для значительного улучшения:

setvbuf(stdin, NULL, _IOFBF, 32768);
setvbuf(stdout, NULL, _IOFBF, 32768);

- Редактировать -

Утверждение Магические числа Новый размер буфера. По умолчанию файл использует буфер из 512 байтов. Увеличение этого размера Уменьшает количество раз, когда библиотека Runtime C ++ должна выдать вызов чтения или записи в операционную систему, которая является самой дорогой операцией в вашем алгоритме.

Поддерживая размер буфера кратным из 512, что исключает фрагментацию буфера. Если размер должен быть 1024 * 10 или 1024 * 1024 зависит от системы, на которую он предназначен для работы. Для 16-битных систем размер буфера размером более 32K или 64K, как правило, вызывает трудности в выделении буфера и, возможно, может управлять им. Для любой более крупной системы сделайте его максимально полезными - в зависимости от доступной памяти и что еще она будет соревноваться.

Не хватает какого-либо известного рациона памяти, выберите размеры для буферов при размере связанных файлов. То есть, если входной файл составляет 250к, используйте это как размер буфера. Определенно появляется убыточный возврат, так как размер буфера увеличивается. Для примера 250k буфер 100K потребует три чтения, в то время как по умолчанию 512 байтовый буфер требует 500 чтения. Дальнейшее увеличение размера буфера, поэтому требуется только одно читание, вряд ли будет создавать значительное улучшение производительности в течение трех чтения.

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

не будет работать:

если (оператор) сделай это; и это; еще сделать это;

Я использую кодовую формулу IDE, которую я использую. Он может отличаться, но его можно настроить в разделе Параметры/Параметры.

Мне нравится этот:

if (statement)
{
    // comment to denote in words the case
    do this;
    // keep this block simple, if more than 10-15 lines needed, I add a function for it
}
else
{
    do this;
}

Мой общий шаблон в том, что если он помещается на одной строке, я сделаю:

if(true) do_something();

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

if(true) {
    do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}

if(false) {
    do_something();
} else {
    do_something_else();
}

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

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

Вот некоторые ссылки на использование брекетов:

• предпочитают многоуровневые скобки, если

• пропущенные брекеты: не просто вопрос стиля

• переполнение стека

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

Я предпочитаю ставить кудрявую скобу. Но иногда тройной оператор помогает.

вместо:

int x = 0;
if (condition) {
    x = 30;
} else {
    x = 10;
}

нужно просто сделать: int x = условие? 30: 20;

также представляют случай:

if (condition)
    x = 30;
else if (condition1)
    x = 10;
else if (condition2)
    x = 20;

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

Одной из проблем с отъездом оттесничных блоков является остальная двусмысленность. То есть C-вдохновленные языки игнорируют отступ и так не имеют никакого способа отделения этого:

if(one)
    if(two)
        foo();
    else
        bar();

из этого:

if(one)
    if(two)
        foo();
else
    bar();

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

Пример:

if (argument == null)
    throw new ArgumentNullException("argument");

if (argument < 0)
    return false;

В противном случае я использую второй стиль.