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


Я видел такой код:

if(statement)
    do this;
else
    do this;

мне это не нравится, я думаю, что это чище и читабельнее

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

Это просто вопрос предпочтения или один способ будет рекомендован по сравнению с другим?

15 87

15 ответов:

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

ремонтопригодность-мудрый, это всегда умнее использовать вторую форму.

EDIT: Нед указывает на это в комментариях, но здесь тоже стоит ссылаться, я думаю. Это не просто какая-то гипотетическая фигня из слоновой кости: https://www.imperialviolet.org/2014/02/22/applebug.html

одна проблема с опущением блоков операторов-это еще-двусмысленность. То есть c-вдохновленные языки игнорируют отступы и поэтому не имеют возможности разделить это:

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

из этого:

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

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

if(true) do_something();

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

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

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

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

Я использую форматер кода 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 (statement)
     do this;
else
     do this;
     do that;

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

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

выглядит гораздо лучше, как это:

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

но используйте только тернарный оператор, если вы абсолютно уверены, что больше ничего не нужно делать в блоках if/else!

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

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

"правило", которому я следую, таково:

если оператор " if " тестируется для того, чтобы что-то сделать (т. е. вызвать функции, настроить переменные и т. д.), используйте фигурные скобки.

if($test)
{
    doSomething();
}

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

Если оператор " if " тестирует, чтобы прекратить что-то делать (т. е. управление потоком в цикле или функции), используйте одну строку.

if($test) continue;
if($test) break;
if($test) return;

в этом случае для программиста важно быстро обнаружить, что исключительные случаи, когда вы не хотите, чтобы код выполнялся, и все это покрывается в $test, а не в блоке выполнения.

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

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

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

if statement:
    do this
else:
    do this

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

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

не работает:

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

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

пример:

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

if (argument < 0)
    return false;

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

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

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

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

один из самых важным правилом, которое следует помнить при написании кода, является согласованность. Каждая строка кода должна быть написана одинаково, независимо от того, кто это написал. Будучи строгим предотвращает ошибки от "происходит" ;)

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

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

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

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

if( statement ) {

    // let's do this

} else {

    // well that sucks

}

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

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

вместо :

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

нужно сделать : int x = condition ? 30 : 20;

представьте себе такой случай :

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

было бы гораздо лучше, если бы вы положили фигурную скобку.