Обслуговування розумне, чи "ще поки" без втручання брекетів вважається безпечним?

Невже else whileбез втручання брекетів вважається "безпечним" технічне обслуговування?

Написання if-elseкоду без дужок, як нижче ...

if (blah)
    foo();
else
    bar();

... несе ризик, оскільки відсутність дужок дозволяє дуже легко змінити значення коду ненавмисно.

Однак нижче також ризиковано?

if (blah)
{
    ...
}
else while (!bloop())
{
    bar();
}

Або else whileбез втручання брекетів вважається "безпечним"?

Це нагадує мені цей код:

if ( ... ) try {
..
} catch (Exception e) {
..
} else {
...
}

Кожен раз, коли ви поєднуєте два типи блоків, забуваючи дужки та не збільшуючи відступ, ви створюєте код дуже важко для розуміння та підтримки.

Можливо, це тому, що я навчився моїй торгівлі (назад, коли), використовуючи метод діаграми структури Джексона Субстанції , але я підписуюся на думку, що єдиний правильний необмежений термін після ifабо else- це наступний if(тобто дозволяючи else ifсходи)

Все інше (не призначене для каламбуру) залишає потенціал для непорозуміння та / або обслуговування обслуговування. Це головний аспект ідеї ОП - "небезпечний".

Я також був би дуже задумливий щодо того, щоб включити while()ту саму лінію, що і те else- незалежно від того, чи це зроблено чи ні. Мені це правильно не читається ... відсутність зайвих відступів масок, що це elseпункт. А недостатня ясність створює непорозуміння (див. Вище).

Тож у прикладі я б настійно радив / рекомендував (і наполягаю на своїй команді) щодо:

if ( blah )
{
    ...
}
else
{
    while ( !bloop() )
    {
        bar();
    }
}

Звичайно, я також сподівався б побачити відповідні коментарі.

- Редагувати -

Нещодавно Apple постраждала від вразливості SSL, спричиненої поганим виправленням технічного обслуговування - що додало другий рядок до єдиної лінії, що не обмежується. Тож давайте покладемо спати ідею, що безперервні одиночні лінії в порядку?

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

    if(blah)
    {
     ....
    }
    else
    {
       while(!bloop()
       {
        bar;
       }
    }

Я видобув би метод і встиг

if ( blah )
{
    ...
}
else
{
   newMethod();
}

Див. Підхід "метод вилучення", пояснений на веб-сайті каталогу Refactoring :

У вас є фрагмент коду, який можна згрупувати.

Перетворіть фрагмент у метод, ім'я якого пояснює призначення методу.

void printOwing() {
    printBanner();

    //print details
    System.out.println ("name:    " + _name);
    System.out.println ("amount    " + getOutstanding());
}

                                                                                                        

void printOwing() {
    printBanner();
    printDetails(getOutstanding());
}

void printDetails (double outstanding) {
    System.out.println ("name:    " + _name);
    System.out.println ("amount    " + outstanding);
}

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

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

if ( blah )
{
    ...
}
else
{
    while ( !bloop() )
    {
        bar();
    }
}

Добре застосовувати код у блоках. Це робить його простішим і легшим для розуміння та налагодження.

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

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

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

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

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

if (...)
   foo();
else while(...)
   bar();

... Я насправді вважаю це else while(...)чудово " " читабельним! Він навіть читається як звичайна англійська! Але я думаю, що всім це буде дивно, тому що це сказати незвично.

Врешті-решт, ми всі схильні робити це ідіотом, хоча дужками ... бо, ну, ви знаєте.

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

if(blah) {
    foo();
}
else {
    bar();
}

Що настільки не так з брекетами, що так багато людей намагаються уникати їх написання?

Яку проблему точно else whileвирішує?

Підтяжки є дешевими і хорошими, і вони роблять намір коду очевидним і зрозумілим на відміну від розумних і дотепних.

Цитуючи філософію Unix:

Правило ясності: Ясність краща за розум.

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

У цьому немає нічого поганого

if (blah)
    foo();
else
    bar();

так само, як немає нічого поганого

if (blah) foo(); else bar();

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

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

до того ж, я вже бачив цей код:

if (x) foo()
{
  bar();
}

і це написав сам стандарт кодування нацист (який наполягав на дужках для всього).

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

if (blah) {
  blub();
} else
  while (!bloop()) {
    bar();
  }

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

Особисто я знаходжу код, який пропускає дужки та розриви ліній набагато легше для читання, оскільки дозволяє уникнути безладу:

if (blah) blub();
else while (!bloop()) bar();

Але звичайно, багато розробників дуже раді сперечатися про такі речі назавжди і на день.