Чи погана практика використовувати if-оператор без фігурних дужок? [зачинено]

Я бачив такий код:

if(statement)
    do this;
else
    do this;

Однак я вважаю, що це читабельніше:

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

Оскільки обидва методи спрацьовують, чи це просто питання переваги, яке слід використовувати чи який спосіб було б рекомендовано іншим?

Проблема першої версії полягає в тому, що якщо ви повернетесь назад і додасте друге висловлення до пунктів if або else, не пам'ятаючи додавати фігурні дужки, ваш код порушиться несподіваними та забавними способами.

Завдяки технічному обслуговуванню, завжди розумніше використовувати другу форму.

EDIT: Нед вказує на це у коментарях, але тут варто посилатися і на мене. Це не лише деякі гіпотетичні фігни із слонової кістки: https://www.imperialviolet.org/2014/02/22/applebug.html

Однією із проблем, що залишаються блоками операторів, є інша - неоднозначність. Тобто мови, натхнені С, ігнорують відступи, і тому не можна розділяти це:

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

Від цього:

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

Моя загальна схема полягає в тому, що якщо вона відповідає одному рядку, я зроблю:

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

Зрештою, це зводиться до суб'єктивного питання стилю та читабельності. Однак загальний світ програмування в значній мірі розпадається на дві сторони (для мов, які використовують дужки): або використовувати їх весь час без винятку, або використовувати їх весь час за винятком. Я є частиною останньої групи.

Я використовую форматор коду 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;
}

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

Якщо оператор "якщо" тестує для того, щоб зробити щось (функції виклику IE, налаштування змінних тощо), використовуйте дужки.

if($test)
{
    doSomething();
}

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

Якщо оператор "якщо" тестує, щоб перестати щось робити (управління потоком IE в циклі або функції), використовуйте один рядок.

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

У цьому випадку, що важливо для програміста, це швидко виявити, які виняткові випадки, коли ви не хочете запускати код, і все це прикрито в $ test, а не в блоці виконання.

Встановлення брекетів з першого моменту повинно допомогти вам не налагоджувати це:

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

Використовуйте дужки для всіх, якщо заяви навіть прості. Або перепишіть простий, якщо оператор, щоб використовувати термінальний оператор:

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

Набагато приємніше виглядає так:

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

Але використовуйте потрійний оператор лише в тому випадку, якщо ви абсолютно впевнені, що нічого іншого не потрібно робити в блоках if / else!

Я вважаю за краще використовувати брекети. Додавання брекетів полегшує читання та модифікацію.

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

• Віддайте перевагу багаторядковому, якщо

• Опущення брекетів: не просто питання стилю

• Переповнення стека

З мого досвіду, єдина (дуже) незначна перевага першої форми - читабельність коду, друга форма додає "шум".

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

Помилок, що споживають енергію, достатньо, люди просто не повинні відкривати двері для великих витрат часу.

Одне з найважливіших правил, яке слід пам’ятати при написанні коду, - послідовність. Кожен рядок коду має бути написаний однаково, незалежно від того, хто його написав. Будьте суворі, не дозволяє помилкам "траплятися";)

Це те саме, що чітко і чітко називати ваші змінні, методи, файли або з правильним відступом їх ...

Коли мої студенти приймають цей факт, вони перестають боротися проти власного вихідного коду, і вони починають сприймати кодування як дійсно цікаву, стимулюючу та творчу діяльність. Вони кидають виклик своєму розуму, а не нерву!

Це питання переваги. Я особисто використовую обидва стилі, якщо я впевнений, що мені більше не потрібно буде додавати заяви, я використовую перший стиль, але якщо це можливо, я використовую другий. Оскільки ви не можете більше додавати заяви до першого стилю, я чув, що деякі люди рекомендують не використовувати його. Однак другий метод містить додатковий рядок коду, і якщо ви (або ваш проект) використовуєте такий тип кодування, перший спосіб дуже бажаний для простих, якщо операторів:

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

Однак я думаю, що найкраще рішення цієї проблеми - в Python. У блоковій структурі на основі пробілів у вас немає двох різних методів створення оператора if: у вас є лише один:

if statement:
    do this
else:
    do this

Хоча в цьому є "проблема", що ви взагалі не можете використовувати дужки, ви отримуєте користь, що це не більше рядків, що є першим стилем, і він має право додавати більше заяв.

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

Не працює:

якщо (заява) зробити це; і це; ще роблять це;

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

Приклад:

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

if (argument < 0)
    return false;

Інакше я використовую другий стиль.

Мої особисті переваги - це використання суміші пробілів та дужок, як це:

if( statement ) {

    // let's do this

} else {

    // well that sucks

}

Я думаю, що це виглядає чисто і робить мій код дуже легким для читання, а головне - налагодженням.

Я погоджуюсь з більшістю відповідей у ​​тому, що краще бути чітким у своєму коді та використовувати дужки. Особисто я би прийняв набір стандартів кодування і забезпечив би, щоб усі в команді їх знали та відповідали. Де я працюю, ми використовуємо стандарти кодування, опубліковані IDesign.net для проектів .NET.

Я вважаю за краще поставити фігурну дужку. Але іноді допомагає потрійний оператор.

Замість :

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;

Було б набагато краще, якби ви вклали фігурну дужку.