Чому вважається поганою практикою пропускати фігурні брекети? [зачинено]


177

Чому всі кажуть, що я пишу такий код, як це погана практика?

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

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

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

Ви також можете отримати додаткову вигоду від з'єднання usingsразом без відступу мільйона разів.

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

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

if (foo)
    Bar();
    Biz();

Запитання:

  1. Чи не так хочеться використовувати більш компактний синтаксис, який пропонує мова? Люди, які розробляють ці мови, розумні, я не можу уявити, що вони поставлять функцію, яку завжди погано використовувати.
  2. Якщо ми чи не повинні писати код, щоб найменший загальний знаменник міг зрозуміти і не мати проблем з ним?
  3. Чи є ще один аргумент, який я пропускаю?

6
Я погоджуюсь з тобою. Опустіть їх. Період.
Андрій Ронеа

67
Хто дбає про те, як багато ліній, що це є в 2010 році. Монітори широкі, дешеві і з високою роздільною здатністю! Мій монітор - 2048 X 1152, і у мене ДВА з них! Зрозумілість набагато важливіше, ніж збереження 2 вертикальних ліній, коли можна легко ввести тонкі помилки, які важко знайти.

51
Монітори широкі та дешеві, але вони не високі та дешеві. Вертикальний простір є дефіцитнішим, ніж горизонтальний простір.
Адам каже - Поновіть Моніку

32
@AdamRuth Поверніть їх набік :)
Zachary Yates

16
Таким чином, ви не накручуєтесь, як Apple, з помилкою SSL, знайденою у лютому 2014 року, LOL
Learnvst

Відповіді:


183

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

if(foo)
  // bar();
doSomethingElse();

Крім цього, я, як правило, використовую:

if(foo) bar();

Що піклується про вищезазначений випадок.

EDIT Дякую за уточнення питання, я згоден, ми не повинні писати код на найнижчому загальному знаменнику.


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

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

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

1
Однорядковий стиль також приховує смугу () від тестового покриття. Це буде виглядати прикритим, навіть якщо foo завжди помилковий.
Bohumil Janda

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

156

Швидкість читання ...

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

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Трохи швидше, ніж я читав:

if (condition) DoSomething();

DoSomethingElse();

Я читаю це трохи повільніше, якщо це виглядає так:

if (condition) DoSomething();
DoSomethingElse();

Я читаю це значно повільніше, ніж попереднє:

if (condition) 
    DoSomething();
DoSomethingElse();

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

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

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

if (condition) 
    DoSomething();
    DoSomethingElse();

29
Проблема вирішується, коли у вашому 4-му зразку ви просто ставите порожній рядок після того, як оператор, щоб відокремити його від DoSomethingElse () Це те, що я роблю, і читабельність практично така ж, як і для 1-го зразка (якщо не краще ;-P) Інша справа, що розміщення рядків у групи по 2 або 3 суттєво допомагає читати, ви просто скануєте код набагато швидше.
Piotr Owsiak

6
Можливо, це тому, що я звик до Python, але ставлячи першу фігурну дужку в ту саму лінію, що й оператор if дозволяє мені читати + розуміти її ще швидше.
Ponkadoodle

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

2
Підтяжки носять явний характер. Я дотримуюся цього, дякую.
TheOptimusPrimus

2
В останньому випадку знайдіть оригінального автора та виплескайте його ...;)
Пер Лундберг

55

Якщо це щось маленьке, напишіть це так:

if(foo()) bar();

Якщо достатньо довго, щоб розбитись на дві лінії, використовуйте дужки.


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

10
Хоча не дуже налагоджувач. Як встановити точку розриву на частині "бар"?
Неманя Трифунович

9
@Nemanja: просто поставте курсор на смугу (); і натисніть F9. І VS2005, і VS2008 обробляють точки міжрядкового проходу, якщо це окремі "заяви".
GalacticCowboy

4
GalanticCowboy: Є більше середовищ, ніж тих, кого ви знаєте. :-)

20
Звичайно, але оскільки контекст - це C #, він повинен охоплювати значну більшість користувачів ...
GalacticCowboy

47

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

Ще одна вагома причина завжди використовувати дужки, окрім того, що хтось додає друге твердження до if, може статися щось подібне:

if(a)
   if(b)
     c();
else
   d();

Ви помітили, що інша стаття - це фактично "if (b)"? Ви, напевно, так і робили, але чи довіряєте ви комусь, хто знайомий з цією ґатчею?

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


12
Це один із двох випадків, коли я використовую брекети. Інакше ні.
Андрій Ронеа

3
Це швидше слід писати так, ніби (а & b) ... в першу чергу міркує.
alexander.biskop

8
@ alexander.biskop: Безумовно, ні, оскільки це надає другому блоку інше значення ( !a || !b), ніж або з доданими дужками ( !a) або без ( a && !b).
Ben Voigt

1
@Ben Voigt: Правда! Впав на це ;-) Через півроку і два оновлення пізніше хтось зрозуміє, що твердження, яке я зробив, є невірним ... Звичайно, я не приділяв належної уваги деталям, головним чином тому, що намір за моїм коментарем був іншим, ніж вказуючи технічно правильне перетворення цього if-пункту. Що я мав на увазі, це те, що вкладені вбудовані висловлювання if, як правило, зменшують читабельність (і, отже, простежуваність контрольного потоку), суттєво схожі, і, отже, слід об'єднати в одне твердження (або взагалі обійти). Ура
alexander.biskop

3
@ alexander.biskop: В той же час, налагодження простіше з вкладеними ifs, кожен з простішими умовами, оскільки ви можете зробити один крок на кожен.
Ben Voigt

35

Це не завжди вважається поганою практикою. В Рекомендації Coding Mono Project пропонує не використовувати фігурні дужки , якщо це не потрібно. Те саме для стандартів кодування GNU . Я думаю, що це питання особистого смаку, як завжди, щодо стандартів кодування.


2
Перегляд коду Mono здається мені досить чужим після прочитання цілого настанови.
dance2die

35

Лінії дешеві. Потужність процесора дешева. Час для розробників коштує дуже дорого.

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

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

(b) Прокоментуйте конкретні частини коду, які можуть знадобитися

(c) Неважко налагодити, якщо щось піде не так

(d) Легко змінювати, якщо це потрібно буде в майбутньому (тобто додавання / видалення коду)

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

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


9
Ваше останнє твердження про (а) - це думка, що велика кількість розробників, включаючи інші афіші тут, можуть стверджувати.
Келлі С. Французька

34

Я віддаю перевагу чіткість, яку пропонує фігурний брекет. Ви точно знаєте, що мається на увазі, і не потрібно здогадуватися, чи хтось просто обдурив і залишив їх (і ввів помилку). Єдиний раз, коли я їх опускаю, - це коли я ставлю значення if і action на одну лінію. Я теж цього не роблю дуже часто. Насправді я віддаю перевагу пробілу, введеному фігурною дужкою на власну лінію, хоча, починаючи з років програмування, подібного K & R C, закінчення лінії дужкою - це практика, яку я повинен працювати, щоб подолати, якщо IDE не застосовує її для я.

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}

23

Я думаю, що це питання настанов щодо проекту, над яким ви працюєте, та особистого смаку.

Зазвичай я їх опускаю, коли вони не потрібні, за винятком таких випадків:

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

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

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}

15

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

Якщо ви не дуже обережні при створенні макросів, у вас можуть виникнути проблеми, якщо заяви, які не використовують {}.

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

Тепер, не зрозумійте мене неправильно, я не кажу, що ви завжди повинні робити {} просто, щоб уникнути цієї проблеми в C / C ++, але мені довелося стикатися з дуже дивними помилками через це.


2
якщо б лише весь код заявив про себе як такий ... зітхніть
Натан Сильний

15

Я використовую, щоб думати так само.

Доки одного дня (чому завжди існує той "один день", який назавжди змінить ваше життя?) Ми витрачаємо 24 - 36 годин прямо без сну, налагоджуючи виробничий код, лише щоб з'ясувати, хто не поставив брекети в поєднанні зі зміною пошуку / заміни .

Це було щось подібне.

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

Те, що прийшло після, було

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

Виявляється, система генерувала 500 mb журналів щодня, і нас попросили припинити. Прапор налагодження було недостатньо, тому пошук і заміна println були в порядку.

Однак, коли додаток було запущено, прапор налагодження був вимкнений, і важливу "saveDayData" ніколи не називали.

EDIT

Тепер єдине місце, де я не користуюсь брекетами, - це конструкція if / try.

if( object != null ) try { 
     object.close();
} catch( .....

Після перегляду розробника суперзірки це робив.


3
Я не розумію. У вас є змінна, яка контролює налагодження (debugEnabled), і ви все ще використовуєте коментарі для відключення налагодження ??? Чому ви просто не встановили налагодженняEnabled на false?
Ігор Попов

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

1
@igor Як щодо того, що вони просто хотіли видалити один рядок ведення журналу не всіх рядків реєстрації?
gman

14

Щоб бути тупим, я вважаю це:

Хороші програмісти програмують оборонно, погані програмісти - ні.

Оскільки є кілька прикладів вище, і мій власний подібний досвід із помилками, пов’язаними із забуванням брекетів, то я навчився важкому шляху ЗАВЖДИ ВИСТАВИТИ БРЕЦИ.

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

Джоел навіть згадує про це у “ Здійсненню помилкового коду”

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


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

14

Я дуже радий:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

Особисто я не розумію, чому

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

є більш читабельним.

Так, рядки безкоштовні, але чому я повинен прокручувати сторінки та сторінки коду, коли він може бути вдвічі меншим?

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

Крім того, я завжди буду ставити дужки для вкладених, якщо там я вклав чужі

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

проти

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

це жахливо заплутано, тому я завжди пишу це як:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

Коли це можливо, я використовую потрійних операторів, але ніколи їх не вкладаю .


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

10

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

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


10

Моя філософія полягає в тому, що якщо він робить код більш читабельним, то чому б не зробити цього?

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

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


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

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

10

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

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

Інакше у мене немає проблем з цим.


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

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

2
Це трапляється. Це не означає, що це має статися.
Адам Яскевич

3
@AdamJaskiewicz Праворуч Це трапляється. Ми повинні думати про те, що відбувається, а не про те, що має статися. Якби ми могли обмежитися тим, що має статися, нам не потрібно буде турбуватися про помилки.
Беска

10

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

Я бачив

if (...)
    foo();
    bar();

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

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


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

@Bob: Добре, і я це роблю лише зрідка. Я не хотів би робити вигляд , що у мене є реальні причини тут :) На насправді, є розумна причина - місце гніздування в usings (і тільки usings) , як , що досить очевидно, і ви до сих пір в кінцевому підсумку з в блоці. Я не можу відразу побачити небезпеку.
Джон Скіт

Який не повинен сказати , що це не якась -то небезпека, звичайно.
Джон Скіт

1
Найкраще рішення цієї помилки: Використовуйте Python. (Жартує, звичайно.)
Джоель Вітелманн

10

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

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

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

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

  • Деякі популярні мови усувають проблему, змушуючи комп'ютер зчитувати відступи, як і програміст (наприклад, Python).

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

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

  • Рефакторинг та виразність мови означають, що мої блоки набагато коротші, а однорядкові блоки трапляються набагато частіше, ніж раніше. Гіпотетично, з нещадним застосуванням ExtractMethod, я міг би мати лише однолінійні блоки у всій своїй програмі. (Цікаво, як це могло б виглядати?)

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

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

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


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

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

9

З трьох конвенцій:

if(addCurleyBraces()) bugFreeSofware.hooray();

і:

if(addCurleyBraces())
    bugFreeSofware.hooray();

і (які представляють будь-який стиль відступу з використанням отвору та дужки закриття):

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

Я віддаю перевагу останній як:

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

8

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

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

І відступ не залежить від використання дужок. У вашому каскадному прикладі "використання" я все-таки думаю, що вам слід відкласти їх, навіть якщо ви опускаєте дужки.


8

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

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

if(x < y)
    x = y;
else
    y = x;

І ще подібний;

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

Я вважаю за краще просто вибрати один загальний стиль і дотримуватися його :)


7

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

Наприклад:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}

4
Чому у вас все-таки є кілька сторінок коду для циклу?
Адам Яскевич

б / с Я нечутливий учасник, і я одержимий позбавленням від "вартості" функціональних дзвінків. :)
чемпіон

4
Кілька сторінок коду, як правило, повинні бути в окремій функції.
Джонатан Леффлер

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

7

Раніше я був великим прихильником "фігурних брекетів ОБОВ'ЯЗКОВО!", Але, прийнявши тестові одиниці, я вважаю, що мої тестові одиниці захищають тверді твердження від таких сценаріїв, як:

if (foo)
    snafu();
    bar();

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

Альтернативно, для чогось подібного, я б, швидше за все, так виглядав:

if (foo) snafu();

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


2
Ви сказали, що "мені це не потрібно", а потім дали причину його використання: читабельність!
tvanfosson

4
Я б не покладався на одиничний тест, щоб знайти це. ЛІНТ, можливо, одиничний тест немає!
Крістен

2
@Kristen - ідея одиничного тесту полягає у твердженні поведінки методу. Якщо поведінка зміниться (як описано вище), тест блоку не вдасться. Я не бачу проблеми в цьому.
Liggy

Але навіщо покладатися на Unit Test, щоб підібрати яскраво очевидно, що слід виправити перед тим, як перейти до UT?
Андрій

7

Скористайтеся деяким особистим судженням.

if (foo)
  bar();

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

if (foo)
  bar();
  baz();

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

В обмін це набагато читабельніше.

Решта часу:

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

Що було моїм улюбленим до тих пір, як я пам'ятаю. Додатково:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

Працює для мене.

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


Єдиний раз, коли я віддаю перевагу першому стилю, це коли мені потрібно негайно повернутися або викинути помилку, якщо щось не так. Як if (parameter == null) return null;.
nawfal

7

Гаразд, це старе питання, на яке відповіли смертю. Мені є що додати.

По-перше, я просто повинен сказати, ВИКОРИСТУВАТИ ГРАНИ. Вони можуть лише допомогти читати, і читабельність (для себе та інших!) Повинна бути дуже високою у вашому списку пріоритетів, якщо ви не пишете збірку. Код, який не читається завжди, завжди призводить до помилок. Якщо ви виявите, що в дужках ваш код займає занадто багато місця, ваші методи, ймовірно, занадто довгі. Більшість або всі способи повинні відповідати одній висоті екрану, якщо ви робите це правильно, а Find (F3) - ваш друг.

Тепер для мого доповнення: з цим є проблема:

if (foo) bar();

Спробуйте встановити точку розриву, яка буде потрапляти лише у тому випадку, якщо bar () буде працювати. Ви можете зробити це в C #, поставивши курсор на другу половину коду, але це не очевидно і викликає біль. У C ++ ви взагалі не могли цього зробити. Один з наших найстаріших розробників, який працює над кодом C ++, наполягає на тому, щоб з цієї причини розбити операції "if" на два рядки. І я з ним згоден.

Тож зробіть це:

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}

2
Клацніть правою кнопкою миші на панелі та виберіть Вставити точку розриву ... Зовсім не важко. Знайте свої інструменти.
Боб

Клацання правою кнопкою миші на індикаторі нічого не робить; ти маєш на увазі правою кнопкою миші текст? У будь-якому випадку, якщо ви хочете, щоб точка перерви була досягнута лише тоді, коли вислів "якщо" є істинним, а "bar ()" знаходиться у своєму рядку, ви можете поставити курсор кудись у цьому рядку та натиснути клавішу F9 або клацнути лівою кнопкою миші показник запасу. Якщо, однак, увесь код знаходиться в одному рядку, перед тим, як натиснути клавішу F9, слід розташувати курсор на "bar ()" або клацнути правою кнопкою миші там точно, і натискання межі поля індикатора не буде працювати (ставить точку розриву на " якщо '). Це не "важко", але воно вимагає меншої концентрації, коли код знаходиться у двох рядках.
камінь

О, ха-ха, клацніть правою кнопкою миші на "бар ()." Ви мали на увазі текст. Готча. Звичайно, або просто натисніть F9 ...
камінь

>> ви повинні розташувати курсор на "bar ()" або клацнути правою кнопкою миші саме там, перш ніж натиснути F9, (я мав на увазі розташування курсора саме там перед натисканням клавіші F9 або клацанням правою кнопкою миші)
камінь

7

для того, щоб код з дужками не зайняв багато місця, я використовую техніку, рекомендовану в книзі Code Complete :

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

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

2
Цей більш відомий як стиль K&R. За матеріалами книги «Мова програмування на Керніган та Річі»: en.wikipedia.org/wiki/The_C_Programming_Language_(book) . І це не повинно вас зменшити.
jmucchiello

Дякую! Я подумав, що це просто особистий смак. Раніше я вважав, що цей синтаксис дратує себе, але я його прийняв, прочитавши Code Complete, і зараз дуже насолоджуюся ним.
Натан Пратер

я читав усі відповіді вище цього, думаючи: "чому ще ніхто цього не запропонував ???" Це змушує дужку закриття вирівнювати з блоком, який він закриває, тобто "якщо" або "поки" тощо, а не безглуздим "{". +1.
nickf

Якщо відкриті дужки завжди розміщуються на рядках самі по собі, то, за ifяким слідує одна відрізна лінія, може бути візуально розпізнано як контроль над одним оператором без необхідності жодних дужок. Таким чином, стиль open-brace-by-last економить пробіл у ситуації, коли ifоператор контролює щось, що семантично є однією дією (на відміну від послідовності кроків, які бувають, що містять лише один крок). Наприклад, if (someCondition)/ `кинути новий SomeException (...)`.
supercat

6

Скажімо, у вас є якийсь код:

if (foo)
    bar();

а потім приходить хтось інший і додає:

if (foo)
    snafu();
    bar();

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


Про це вже було сказано в питанні.
Майк Скотт

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

Чи дійсно є таке поняття, як код підтвердження помилок?
Боб

Ні, але ви можете зробити це складніше. Прочитайте "Кращі збережені секрети рецензування коду експертів" Джейсона Коена (див. Посилання збоку на деяких сторінках тут), щоб краще зрозуміти, чому ви це робите.
Елі

Хто цей Майк Скотт і чому він відповідає поліції? Мене завжди тріскає, що люди повинні констатувати те, що очевидно. То чому б Майк не продовжував коментувати доданий опис, який користувачі публікують з цього приводу. Чи не всі відповіді на це питання?
bruceatk

6

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


5

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

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

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


4

У більшості випадків він використовується як стандарт кодування, як для компанії, так і для проекту FOSS.

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

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


+1 для коментаря про python. Мене завжди дивує, наскільки я "дурним" можу бути, коли постійно перемикаюся між мовами.
Кена

3

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

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

Якщо у мене є однолінійка, я зазвичай її форматую так:

if( some_condition ) { do_some_operation; }

Якщо лінія є занадто громіздкою, то використовуйте наступне:

if( some_condition )
{
    do_some_operation;
}
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.