Єдине твердження, якщо блок - дужки чи ні? [зачинено]

Що краще / загальніше прийнято?

Це:

if(condition)
{
  statement;
}

Або:

if(condition)
  statement;

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

Перше краще, оскільки друге схильне до помилок. Наприклад, скажімо, ви тимчасово коментуєте код, щоб щось налагодити:

if(condition) 
//      statement;
otherStatement;

Або додавання коду поспіхом:

if(condition) 
    statement;
    otherStatement;

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

if(condition) statement;

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

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

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

Я вважаю за краще версію без дужок, де це можливо.

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

(Поблизу) порожні рядки - це марно

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

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

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

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

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

Так само повинні бути лінії, які просто містять дужку, і які можна економити. Блок з одним оператором, який розмежований дужками, відходить один-два рядки. Маючи лише 50 лінійних рядків на висоту екрану, це помітно.

Пропуск брекетів може не нашкодити

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

Це дійсно було б великою справою.

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

Я навіть вважаю малоймовірним, що це має бути поширеною помилкою: блоки - це основна частина програмування. Роздільна здатність і визначення рівня блоків - це автоматичний розумовий процес для програмістів. Мозок просто це робить (інакше міркувати про програмування було б набагато важче). Не потрібно додаткового розумового зусилля, щоб запам'ятати ставлення дужок: програміст також пам’ятає правильно відступити щойно доданий вислів; тож програміст вже подумки обробив, що задіяний блок.

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

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

¹ Ця проблема іноді вирішується, якщо все - включаючи брекети - розміщувати на одній лінії:

if (condition)
{ do_something(); }

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

Я йду з другим. Це більш лаконічно і менш багатослівно.

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

Я використовую наступне (консенсус тут):

if (condition) {
    any_number_of_statements;
}

Також можливі:

if(condition) single_compact_statement;

Не дуже добре, особливо на мовах, що відповідають C / C ++:

if(condition) 
    single_compact_statement;

(Тут немає вибору в Python ;-)

У Perl ви використовуєте:

$C = $A**3 if $A != $B;

або

$C = $A**3 unless $A == $B;

(Це не псевдокод ;-)

Я використовую метод брекетів - з усіх наведених вище причин плюс ще одна.

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

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

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

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

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

З іншого боку, ReSharper автоматично додасть дужки для лінивих програмістів у Visual Studio, і я припускаю, що є додатки для інших IDE, які також будуть робити це.

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

"Не змушуйте мене думати" не стосується лише інтерфейсів користувача, ви ;-)

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

На це я кажу "не використовуйте макроси". Я також кажу: "правильно вставте проклятий код". З огляду на те, як кожен текстовий редактор / IDE, використовуваний для програмування, робить відступ автоматично, це робити не повинно. Коли пишуть код в Emacs, я б використовував автовідступ для ідентифікації, якщо я написав щось не так у попередньому рядку. Щоразу, коли Emacs починає викручувати відступи, я зазвичай знаю, що я щось зробив не так.

На практиці я закінчую, дотримуючись будь-якої конвенції кодування, яка була поставлена ​​перед мною. Але ці мене дратують (і роблять мене набагато щасливішим, коли я кодую в Python, і вся ця дужка катастрофи минула):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Тоді

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

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

Я використовую дворядкову версію без дужок (2 клас), але не для економії місця.

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

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

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

Нижче наведено кілька прикладів, які демонструють, як я використовую цю форму ifтвердження.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Брекети. Завжди. Я їх прихильник, бо це надає коду певної послідовності. А також як писав @dsimcha - менше шансів на помилки при додаванні додаткових рядків коду.

"Потворність" брекетів навколо одного рядка коду менш шкідлива, ніж додаткова робота, яка є ймовірною у випадках налагодження та / або додавання коду.

Особисто я йду з дужками.

Чому?

Добре, якщо хтось підійде і йому потрібно додати код до оператора if, то на 100% зрозуміло, де область.

Він підтримує формат ifвисловлювань послідовним незалежно від того, скільки заяв є в блоці.

Однак, якщо стиль проекту не обійдеться, дотримуйтесь цього.

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

if (x==5) Console.WriteLine("It's a five!");

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

If (cond) { statement; }

Я зазвичай використовую брекети, але бувають випадки, коли я цього не роблю.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

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

Якщо в IDE доступне форматування коду, я не використовую дужки.

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