Чи повинні фігурні брекети з’являтися на власній лінії? [зачинено]

Повинні бути фігурні брекети на власній лінії чи ні? Що ви думаєте про це?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

чи має бути

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

або навіть

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Будьте конструктивні! Поясніть, чому поділіться досвідом, підкріпіть це фактами та посиланнями.

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

Але при кодуванні великих додатків, дозволяючи деяким рядкам із лише дужками в них доступні, враховуючи відчуття «групування», яке воно дає.

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

Ніколи не слід робити 3-й метод.

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

Напишіть свій код для інших людей.

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

Однак, важливо бути послідовними . Тому я сказав, давайте перекинемо монету і перейдемо до написання коду.

Я бачив, як програмісти чинили опір таким змін. Закінчуй з цим! Я багато разів перемикався в кар’єрі. Я навіть використовую різні стилі в своєму C #, ніж в моєму PowerShell.

Кілька років тому я працював над командою (~ 20 розробників), яка вирішила попросити інформацію, а потім прийняти рішення, а потім застосувати це по всій базі коду. У нас був би тиждень, щоб вирішити.

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

Коли ми вивчали точніші питання, хтось запитував, як вирішити цю проблему в стилі brace-on-the-line:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Зауважте, що не відразу очевидно, де закінчується список параметрів, і починається тіло. Порівняти з:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

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

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

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

Редагувати : дві варіанти рішення "додаткової порожньої лінії" при використанні K&R:

1 / Введіть аргументи функції на відміну від тіла функції

2 / Помістіть перший аргумент у той самий рядок із назвою функції та вирівняйте подальші аргументи у нових рядках до цього першого аргументу

Приклади:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/ Редагувати

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

Основними правилами є:

1. Дотримуйтесь існуючого стандарту кодування проекту.
2. Якщо немає стандарту кодування, і ви редагуєте наявну базу коду, що належить комусь іншому, - будьте узгоджені зі стилем існуючого коду, незалежно від того, наскільки вам це подобається / не подобається.
3. Якщо ви працюєте над проектом «екологічного поля» - обговоріть з іншими членами команди та прийдіть до консенсусу щодо формального чи неофіційного стандарту кодування.
4. Якщо ви працюєте над проектом «зеленого поля» як єдиний розробник - вирішите власний розум і будьте безжально послідовними.

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

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

Перевага першого методу полягає в тому, що він більш вертикально компактний, тому ви можете розмістити більше коду на екрані, і саме тому я віддаю перевагу цьому. Єдиний аргумент, який я чув на користь другого методу, полягає в тому, що це полегшує парне відкривання та закривання дужок, але більшість IDE мають для цього комбінацію клавіш, і це фактично помилкове твердження - замість того, щоб з'єднувати відкривальну дужку до закриття В дужці ви можете з’єднати дужку, що закривається, на вираз "початок блоку" (якщо, інакше, для, поки) на тому ж рівні відступу, тож так само просто визначити, де починається блок.

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

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

я віддаю перевагу

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

над

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

адже рядок you.postAnswer();набагато простіше читати та знаходити на перший погляд. По-друге, вона поєднується з лінією над нею ( you.hasAnswer()), завдяки чому мої очі повинні більше зосереджуватися, щоб її прочитати.

Я віддаю перевагу першому методу. Підтяжки зовсім не варто окремої лінії.

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

Є мови (Python, Haskell, Ruby), які взагалі в порядку без дужок. Це лише підтверджує, що брекети - це сміття, і вони не повинні заслуговувати на них рядки, коли це можливо:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}

Використовуйте Python і повністю убік аргументуйте.

Положення фігурних брекетів повинно бути

метадані

Конфігурується в IDE програмістом. Таким чином, ці дотепні дужки у всьому коді, незалежно від автора, виглядають однаково.

Це залежить.

Якщо я кодую в Javascript або jQuery, я використовую першу форму:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

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

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Зауважте, що ваш приклад можна написати

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

в C #.

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

if (value > maximum);
{
    dosomething();
}

ніж це в цьому прикладі

if (value > maximum); {
    dosomething();
}

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

Я вважаю за краще незначний варіант 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Чому?

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

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

• 3) дискваліфікує себе. Всі ми знаємо, що поганого може статися, якщо ви не виставите дужки і забудете про це.

Я десь читав, що автори якоїсь книги хочуть, щоб їх код був відформатований так:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Але обмеження місця у видавця означало, що вони повинні використовувати це:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

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

На особистому рівні я віддаю перевагу дужкам в окремому рядку як:

а) вони вказують на нову область застосування
;

Ах, єдиний справжній стиль дужки .

У ній є все необхідне для Святого шляху - навіть пророк (Річард «мій шлях або шосе» Столман).

Хлопець настільки помилявся з приводу стількох речей, але GNU спотонована, коли мова йде про брекети.

[Оновлення] Я побачив світло, і тепер поклоняюся Алману

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

Проста відповідь: що простіше налагодити?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

У якому випадку ви поставили діагноз спочатку?

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

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

Не те, що хтось помітить, але саме тому брекети належать до тієї ж лінії , що і умовні (за винятком дуже довгих умов, але це крайній випадок):

У C це допустима конструкція:

поки (правда);
{
    char c;
    getchar (); // Зачекайте на введення
}

Швидкий! Що робить цей код? Якщо ви відповіли "нескінченна петля з проханням про введення", ви помиляєтесь! Він навіть не потрапляє на вхід. Це потрапляє while(true). Зауважте цю крапку з комою в кінці. Ця закономірність насправді частіше зустрічається, що здається, що має бути; C вимагає, щоб ви оголосили свої змінні на початку блоку, саме тому було запущено нову.

Рядок коду - це думка. Підтяжки - це частина думки, що містить умовний або цикл. Тому вони належать до однієї лінії.

Мені подобається перший метод. Здається, акуратніше ІМО, і це компактніше, що мені подобається.

EDIT: Ах, третя. Мені подобається той найкращий, коли це можливо, оскільки він ще менший / охайніший.

Ви можете це написати:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Відповісти на запитання; Раніше я віддав перевагу фігурним брекетам в їх власній лінії, але, щоб не думати про помилки в автоматичній вставці крапки з комою в браузери, я почав використовувати єгипетський стиль для JavaScript. І при кодуванні Java в затемнення я не мав інтересу в боротьбі (або налаштування) стилю брекетів за замовчуванням, тому я і в цьому випадку пішов з єгипетським. Зараз я добре з обома.

Майже всі відповіді тут говорять про певну зміну на тему "Що б ти не робив, дотримуйся одного чи двох".

Тож я на мить подумав про це і повинен був визнати, що просто не вважаю це таким важливим. Хтось може чесно сказати мені, що важко слідувати наступному?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

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

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

FWIW, наші стилі кодування на роботі використовують дещо більш структуровану форму 1 та модифіковану форму 3. (C ++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

Мені цікаво, якщо ті, хто сильно вважає за краще формуляр 2, знайдуть цю версію форми 1 краще, просто тому, що порожня лінія дає сильнішу зорову відокремленість.

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

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

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

Мені особисто подобається другий спосіб.

Однак спосіб, який я продемонструю, на мій погляд, найкращий, оскільки це призводить до найбільшої безпеки роботи! Студентка з мого університету попросила мене допомогти з його домашнім завданням, і ось як виглядав його код. Вся програма виглядала як один єдиний блок. Цікавим є те, що 95% помилок у програмі, яку він робив, виходили з невідповідних брекетів. Інші 5% були очевидні, коли брекети були зіставлені.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);

Мої особисті переваги - це перший метод, мабуть тому, що саме так я вперше вивчив PHP.

Для однорядкових ifвисловлювань я буду використовувати

if (you.hasAnswer()) you.postAnswer();

Якщо це не you.postAnswer();щось, а щось набагато довше, наприклад, you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);я, мабуть, повернуся до першого типу:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Я ніколи не буду використовувати переривання рядків, і я ніколи не буду використовувати цей метод, якщо також є elseзаява.

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

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

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Вони не повинні; Перший метод для мене.

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

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

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

Це залежить від платформи / мови / умов

На Java:

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

В C #

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

В:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Я ненавиджу, коли хлопці Java використовують свій стиль у коді C # і навпаки.

Все, що я можу сказати, - це те, що якщо ви любитель методу №3, вас переслідують усі формати-коди IDE на землі.

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

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

Але; найголовніше з усіх - послідовність. Використовуйте те чи інше - ніколи обом!

Коли я вперше навчався програмуванню в 12, я поставив дужки на наступному рядку, оскільки навчальні посібники з кодування Microsoft подібні. Я також розрізав 4-пробільні таблички TABS.

Через кілька років я дізнався Java та JavaScript, і побачив більше підтяжних кодів на одному рядку, тому я змінився. Я також почав відступати з 2-пробільних просторів.

Існує 4-й варіант, який підтримує вирівнювання брекетів, але не витрачає місця:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

Єдина проблема полягає в тому, що більшість автоформаторів IDE задихаються від цього.

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

Я особисто віддав перевагу 1-му методу.

Також я не отримав те, що ти хочеш показати третім методом?

Це не так? Наприклад, розгляньте ситуацію як ..

if (you.hasAnswer())
  you.postAnswer();
else
  you.doSomething();

А що робити, якщо хтось хоче додати ще кілька тверджень у блок if ?

У тому випадку, якщо ви використовуєте 3-й метод, компілятор видасть синтаксичну помилку.

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();