Почему считается плохой практикой опускать фигурные скобки? [закрыто]

Почему все говорят мне, что написание кода - это плохая практика?

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 и его предполагаемым результатом:

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

Вопросов:

  1. Неправильно ли хотеть использовать более компактный синтаксис, который предлагает язык? Люди, которые проектируют эти языки, умны, я не могу себе представить, что они добавят функцию, которой всегда плохо пользоваться.
  2. Должны ли мы или не должны писать код, чтобы наименьший общий знаменатель мог понять и без проблем работать с ним?
  3. Есть еще один аргумент, который я пропускаю?
11.12.2008 15:34:22
Используйте Python и забудьте об этом :)
Vanuan 19.06.2009 19:57:58
Кто заботится о том, как много линий в 2010 году. Мониторы широкие, дешевые и с высоким разрешением! Мой монитор 2048 X 1152, и у меня их два! Читаемость намного важнее, чем сохранение двух вертикальных линий, когда вы можете легко вносить тонкие ошибки, которые трудно найти.
user177800 24.01.2010 02:20:59
Мониторы широкие и дешевые, но не высокие и дешевые. Вертикальное пространство более скудно, чем горизонтальное.
Adam Says - Reinstate Monica 8.07.2012 22:23:21
@AdamRuth Поверни их в сторону :)
Zachary Yates 8.09.2013 02:12:57
Так что вы не облажаетесь, как Apple, с ошибкой SSL, обнаруженной в феврале 2014 года, LOL.
learnvst 24.02.2014 10:35:53
30 ОТВЕТОВ
РЕШЕНИЕ

На самом деле, единственное время, которое меня действительно поразило, это когда я отлаживал и комментировал bar ():

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

Помимо этого, я склонен использовать:

if(foo) bar();

Который заботится о вышеупомянутом случае.

РЕДАКТИРОВАТЬ Спасибо за разъяснение вопроса, я согласен, мы не должны писать код с наименьшим общим знаменателем.

183
13.12.2008 19:42:51
Это, конечно, грубо, но я думаю, что самая большая проблема для сопровождающих заключается в том, что они добавят вторую строку и не осознают, что это не является частью условного выражения, даже если оно ДЕЙСТВИТЕЛЬНО выглядит так, как должно быть.
danieltalsky 12.12.2008 05:48:32
Мне не нравится стиль с одним вкладышем, потому что я всегда ищу тело петли ниже.
Nosredna 19.06.2009 00:28:22
Я считаю, что однострочный стиль скорее раздражает, чем помогает, потому что (особенно при глубокой вложенности - тьфу) утверждение может быть легко переоценено и может возникнуть путаница. Я почти исключительно использую такие одиночные операторы if для проверки входных данных (т.е. ранних возвратов) или контроля цикла (например, игнорируя нерелевантные имена файлов при обходах файловой системы), где пустые строки помогают выделить их из основного кода.
Alan Plum 5.02.2010 00:10:17
Однострочный стиль также скрывает панель () от тестового покрытия. Это будет выглядеть прикрыто, даже если foo всегда ложно.
Bohumil Janda 13.11.2013 10:02:06
Это еще один способ сказать: «Если бы источник включал фигурные скобки, я бы не стал тратить время на отладку». - добавление фигурных скобок тривиально просто и позволяет избежать ловушек для следующего человека. Единственный аргумент против - это «читабельность», что довольно незначительно, учитывая, что это тот случай, когда что-то неявно происходит, если вы их опускаете.
Andrew Theken 28.08.2014 13:28:14

Допустим, у вас есть код:

if (foo)
    bar();

а потом приходит кто-то еще и добавляет:

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

Согласно написанному, bar (); сейчас выполняется безоговорочно. Включая фигурные скобки, вы предотвращаете такую ​​случайную ошибку. Код должен быть написан таким образом, чтобы сделать такие ошибки трудными или невозможными для совершения. Если бы я делал обзор кода и увидел недостающие скобки, особенно разбросанные по нескольким строкам, я бы создал дефект. В тех случаях, когда это оправдано, держите его в одной строке, чтобы вероятность такой ошибки снова была сведена к минимуму.

6
11.12.2008 15:37:44
Эта точка зрения уже была высказана в вопросе.
Mike Scott 11.12.2008 15:46:11
Не совсем, на самом деле. Да, он упомянул о возможной ошибке такого рода, но я говорил о том, чтобы сделать ваш код защищенным от ошибок и устранить вероятность ошибок как часть лучших практик.
Elie 11.12.2008 15:50:29
Есть ли такая вещь, как код ошибки?
Bob 11.12.2008 15:56:07
Нет, но вы можете сделать это более сложным. Прочитайте «Лучшие секреты рецензирования кода» Джейсона Коэна (см. Ссылку на некоторых страницах здесь), чтобы лучше понять, почему вы это делаете.
Elie 11.12.2008 16:07:06
Кто этот Майк Скотт и почему он ответит полиции? Меня всегда раздражает, что люди должны заявить, что очевидно. Так почему же Майк не стал комментировать добавленное описание, которое пользователи публикуют об этой проблеме? Разве не все ответы относятся к вопросу?
bruceatk 11.12.2008 16:21:47

Ваш программист по обслуживанию может забыть добавить фигурные скобки позже, если он / она добавляет логику в приложение. Так происходит следующее:

if(foo)
bar();
bar(delete);

Вместо

if(foo) {
bar();
}
 bar(delete);
1
11.12.2008 15:38:38
Эта точка зрения была сделана в вопросе.
Mike Scott 11.12.2008 15:46:46
Майк: Тогда разве это не должно быть закрыто как «не настоящий вопрос»? Другие высказали это мнение, вы их тоже голосовали? В конце концов, это фактический ответ о том, почему это плохая практика.
George Stocker 11.12.2008 15:47:58
Я думаю, что он пытается получить больше значков
Elie 11.12.2008 15:54:53
Это отступление ужасно.
recursive 11.12.2008 16:47:47

Исключения всегда есть, но я бы не стал использовать фигурные скобки, только когда они в одной из форм:

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

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

В противном случае у меня нет проблем с этим.

10
11.12.2008 16:19:34
Плохие примеры. В обоих случаях я бы выделил 200 строк для цикла в свой собственный метод или, желательно, несколько методов.
Adam Jaskiewicz 11.12.2008 16:02:40
Правда, но это случается. Кроме того, всякий раз, когда блок длиннее экрана читателя, у вас возникнет эта проблема. И вы не можете контролировать высоту экрана вашего читателя кода. Они могут видеть только пару строк на каждой стороне.
rampion 11.12.2008 16:45:15
Это случается Это не значит, что это должно произойти.
Adam Jaskiewicz 11.12.2008 17:48:18
@AdamJaskiewicz Верно. Это случается Мы должны думать о том, что происходит, а не о том , что должно произойти. Если бы мы могли ограничиться тем, что должно произойти, нам не пришлось бы беспокоиться об ошибках.
Beska 16.08.2012 12:45:22

Я иногда использую самый нижний код (множественные операторы использования), но кроме этого я всегда вставляю фигурные скобки. Я просто нахожу, что это делает код более понятным. Из не просто отступа очевидно, что оператор является частью блока (и, следовательно, вероятно, частью if и т. Д.).

Я видел

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

ошибка кусает меня (точнее "я и коллеги" - я фактически не представлял ошибку) один раз . И это несмотря на то, что наши стандарты кодирования в то время рекомендовали использовать фигурные скобки везде. Мне понадобилось удивительно много времени, чтобы увидеть - потому что вы видите то, что хотите увидеть. (Это было около 10 лет назад. Может быть, я бы нашел это быстрее сейчас.)

Конечно, если вы используете «фигурную скобку в конце строки», это уменьшает дополнительные строки, но мне лично этот стиль все равно не нравится. (Я использую это на работе, и нашел это менее неприятным, чем я ожидал, но это все еще немного неприятно.)

10
11.12.2008 19:37:40
Я всегда утверждаю, что последовательность важнее, чем фактический стиль. Почему мы должны делать исключение только в случае использования?
Bob 11.12.2008 15:58:55
@Bob: Хороший вопрос, и я делаю это только изредка. Я не хотел бы делать вид , что у меня есть реальные причины здесь :) На самом деле, есть разумная причина - гнездовье в usings (и только usings) , как , что довольно очевидно, и вы до сих пор в конечном итоге с в блоке. Я не могу сразу увидеть опасность.
Jon Skeet 11.12.2008 16:05:47
Который не должен сказать , что это не какая -то опасность, конечно.
Jon Skeet 11.12.2008 16:06:21
Лучшее решение этой ошибки: используйте Python. (Шучу, конечно.)
Joel Wietelmann 11.12.2008 17:28:25

В большинстве случаев это укоренилось в качестве стандарта кодирования, будь то для компании или проекта FOSS.

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

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

4
11.12.2008 15:41:18
+1 за комментарий о питоне. Я всегда поражаюсь, насколько «глупым» я могу быть при постоянном переключении между языками.
Kena 11.12.2008 16:22:59

Одна из основных проблем - это когда у вас есть области с одним и не одним вкладышами, а также отделение от контрольного статута ( 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
}
7
11.12.2008 15:41:46
Почему в вашем цикле for есть пара страниц кода?
Adam Jaskiewicz 11.12.2008 16:04:01
b / c Я нечувствительный ком, и я одержим избавлением от "стоимости" вызовов функций. :)
rampion 11.12.2008 16:43:37
Обычно пара страниц кода должна быть в отдельной функции.
Jonathan Leffler 11.12.2008 20:10:09
извините, я имел в виду, что играл роль такого кома. Тем не менее, я считаю, что та же проблема может возникнуть в более коротких регионах при просмотре через небольшое окно просмотра. И это вне контроля кодера.
rampion 12.12.2008 03:15:25

Я согласен с тем, что «если вы достаточно умны, чтобы заставить кого-то платить вам за написание кода, вы должны быть достаточно умны, чтобы не полагаться только на отступы, чтобы увидеть поток кода».

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

10
11.12.2008 15:43:02

Это более дешевый код (лучше читаемый) по сравнению с более безопасным (менее подверженный ошибкам).

Мои 2 цента:

  1. Есть причина для этого правила. Он был разработан бесчисленными программистами в течение долгих рабочих часов, тянущихся до ночи или следующего утра, пытаясь исправить ошибку, вызванную небольшим недосмотром.
  2. Вы сами не можете решить, стоит ли это делать.
  3. По моему опыту, я один из тех бесчисленных программистов, которые работали всю ночь, чтобы найти причину неприятной ошибки. Причина была в том, что я ленивый.
0
11.12.2008 15:52:32
Бесчисленные программисты в пункте 1, они лидеры отрасли, за которыми мы должны следовать, или программист типа LCD?
Bob 11.12.2008 16:15:23
Это наши предки, те мифические фигуры, которые в древние времена заложили основы нашего ремесла, каким мы его знаем сегодня. Мы навсегда будем в их отделе. Одной из многих важных работ, которые они сделали, было уничтожение зла, известного как GOTO. (Древние времена = 1970-е - 1990-е годы) 1970-е и 1990-е годы
Treb 11.12.2008 16:25:53

чтобы код с фигурными скобками не занимал много места, я использую технику, рекомендованную в книге Code Complete :

if (...) {
    foo();
    bar();
}
else {
    ...
}
7
24.03.2013 01:13:11
Я не понимаю, почему он был понижен, он сохраняет одну строку для каждой пары скобок, я использую это все время
Eric 11.12.2008 23:08:02
Это более известный как стиль K & R. Основано на книге Кернигана и Ричи «Язык программирования Си»: en.wikipedia.org/wiki/The_C_Programming_Language_(book) . И это не должно вас унизить.
jmucchiello 19.12.2008 03:05:11
Спасибо! Я полагал, что это был только личный вкус. Раньше я находил этот синтаксис раздражающим, но принял его после прочтения Code Complete, и теперь мне действительно нравится.
Nathan Prather 9.01.2009 16:57:35
Я читал все ответы выше этого, думая: «Почему никто еще не предложил это ???» Это выравнивает закрывающую скобку с блоком, который она закрывает, то есть «если» или «пока» и т. Д., А не бессмысленным «{». +1.
nickf 19.06.2009 00:39:31
Если открытые скобки всегда помещаются в строки сами по себе, то знак, ifза которым следует одна строка с отступом, может визуально распознаваться как управляющий одним оператором без необходимости в каких-либо скобках. Таким образом, стиль открытой фигурной скобки сам по себе сохраняет пустое пространство в ситуации, когда ifоператор управляет чем-то, что является семантически единственным действием (в отличие от последовательности шагов, которая содержит только один шаг). Например, if (someCondition)/ `throw new SomeException (...)`.
supercat 15.08.2014 15:29:33

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

Для него легко выйти из-под контроля, если вы начнете выполнять множественные вложения, предложения if / else и т. Д., Но я думаю, что большинство программистов должны быть в состоянии сказать, где провести черту.

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

5
11.12.2008 15:45:45

Ваши основные аргументы против использования фигурных скобок в том, что они используют дополнительные строки и требуют дополнительного отступа.

Строки (почти) свободны, минимизация количества строк в вашем коде не должна быть целью.

И отступ не зависит от использования фигурных скобок. В вашем примере каскадного «использования» я все еще думаю, что вы должны делать отступы, даже если вы опускаете скобки.

8
11.12.2008 16:08:41

Раньше я был большим сторонником «фигурные скобки - это НЕОБХОДИМО!», Но с тех пор, как я принял модульное тестирование, я обнаружил, что мои модульные тесты защищают беспрепятственные утверждения от таких сценариев, как:

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

С помощью хороших модульных тестов я могу с уверенностью опустить фигурные скобки для простых операторов для улучшения читабельности (да, это может быть субъективным).

В качестве альтернативы, для чего-то подобного выше, я бы, скорее всего, добавил это так:

if (foo) snafu();

Таким образом, разработчик, которому нужно добавить bar () к условию, будет более склонен признать отсутствие фигурных скобок и добавить их.

7
11.12.2008 15:46:52
Вы сказали: «Мне это не нужно», а затем объяснили причину его использования: удобочитаемость!
tvanfosson 11.12.2008 15:50:40
Я бы не стал полагаться на юнит тест, чтобы найти это. LINT возможно, модульного теста нет!
Kristen 28.02.2009 07:00:32
@Kristen - Идея модульного теста состоит в том, чтобы установить поведение метода. Если поведение изменяется (как описано выше), модульный тест не пройден. Я не вижу проблемы в этом.
Liggy 27.11.2009 14:05:16
Но зачем полагаться на модульное тестирование, чтобы выявить очевидное, что должно быть исправлено, прежде чем идти в UT?
Andrew 27.09.2012 10:24:24

Если это что-то маленькое, напишите это так:

if(foo()) bar();

Если это достаточно долго, чтобы разбить на две строки, используйте фигурные скобки.

55
11.12.2008 15:47:07
да, я тоже так делаю Он заставляет вас добавлять фигурные скобки, если вы добавляете еще одну строку, и совершенно ясно, что bar () на самом деле является частью if, поэтому плохие вещи могут произойти, если вы просто закомментируете это.
jalf 11.12.2008 16:37:34
Не очень дружественный к отладчику, все же. Как вы устанавливаете точку останова на части «bar»?
Nemanja Trifunovic 11.12.2008 19:17:35
@Nemanja: просто наведите курсор на панель (); и ударил F9. И VS2005, и VS2008 обрабатывают внутристрочные точки останова, если они являются отдельными «операторами».
GalacticCowboy 11.12.2008 19:52:13
GalanticCowboy: Есть больше сред, чем те, которые вы знаете. :-)
user14070 11.12.2008 22:25:13
Конечно, но так как контекст C #, это должно охватывать значительное большинство пользователей ...
GalacticCowboy 12.12.2008 00:18:04

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

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

if (condition) // normal/standard for me
{
   action();
}
34
11.12.2008 15:47:13

Моя философия такова: если это делает код более читабельным, почему бы не сделать это?

Очевидно, что вам нужно провести черту где-то, как найти эту удачную середину между краткими и чрезмерно описательными именами переменных. Но скобки действительно избегают ошибок и улучшают читабельность кода.

Вы можете утверждать, что люди, достаточно умные, чтобы быть программистами, будут достаточно умны, чтобы избежать ошибок, которые могут привести к появлению без скобок. Но можете ли вы честно сказать, что вас никогда не задирала такая простая вещь, как орфографическая ошибка? Подобные мелочи могут быть ошеломляющими при рассмотрении крупных проектов.

10
11.12.2008 15:56:53
Конечно это очень субъективно. Оставляя их выключенными, иногда улучшается читаемость.
Brian Knoblauch 11.12.2008 15:50:44
Правда, если я когда-нибудь опущу скобки, я оставлю одну строку, как уже упоминали другие. Я был укушен слишком много раз, но многострочные заявления без скобок. Даже если вы знаете, что стоит позаботиться об этом, он все равно может иногда вас достать.
James McMahon 11.12.2008 15:54:16

  • Напишите открытую скобку в той же строке, что и предыдущая инструкция:

    if ( any ) {
        DoSomething();
    }

  • Если вы думаете, что это слишком много, вы можете написать это в одну строку:

    if ( any ) { DoSomething(); }

    Если вы думаете, что одна строка не так хорошо читается, вы можете написать ее в две строки:

    if ( any ) {
        DoSomething(); }
    if ( any )
        { DoSomething(); }
    • В будущем кому-то нужно будет изменить одно утверждение на большее. Без скобок смена сложнее. Да только littlebit, но лучше всего предотвращать баги. И написание скобок очень просто и дешево.
  • 2
    26.02.2009 02:17:21
    Закрывающие скобки всегда должны быть на уровне блока, никогда не заканчивая концом последней строки.
    recursive 11.12.2008 16:54:46
    Это даже хуже, чем не использовать скобки.
    FINDarkside 26.01.2019 14:09:09

    Это не всегда считается плохой практикой. В Рекомендации Coding Mono Project предлагает не использовать фигурные скобки , если это не нужно. То же самое для стандартов кодирования GNU . Я думаю, что это вопрос личного вкуса, как всегда со стандартами кодирования.

    35
    11.12.2008 15:48:32
    Глядя на код Mono, мне кажется совершенно чуждым после прочтения всего руководства.
    dance2die 23.10.2009 03:44:29

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

    Я нахожу это очень читабельным: -

    if (foo)
        bar();

    и это:-

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

    Если к ним добавлена ​​дополнительная строка:

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

    Это выглядит все неправильно, есть блок кода с отступом. но не в скобках.

    Аналогичный аргумент верен для цикла for. Однако, когда я начинаю вложить: -

    if (foo)
        if (bar)
            snafu()

    Теперь я сталкиваюсь с неприятностями, это похоже на блок утверждений. Лично я бы пропустил использование фигурных скобок только на один уровень глубже, если бы внешний код использовал фигурные скобки:

    if (foo) {
       if (bar)
           snafu()
    }

    Когда я набираю это, я вижу, как ответы меняются с 1 на 17, очевидно, это будет эмоциональный вопрос (я предлагаю вам добавить субъективное в список тегов (моя способность сделать это пропала, что с этим? )).

    Самое главное, чтобы в команде было соглашение о том, приемлемо ли и насколько это приемлемо, и придерживаться его.

    1
    11.12.2008 15:50:11
    Попробуйте if (foo && bar) snafu (). C # поддерживает короткое замыкание :)
    Brian 19.06.2009 20:00:26

    Вьющиеся фигурные скобки AFAIR всегда являются областью применения, поэтому для них полезно использовать их каждый раз.

    Без брекетов:

    if(DoSomething)
        MyClass myClass = new MyClass();
    
    myClass.DoAnythingElse();

    Это скомпилирует, но легко приведет к нулевым ссылкам. (Компилятор C # не компилирует это, хорошо!)

    Тогда как этот путь:

    if(doSomething)
    {
        MyClass myClass = new MyClass();
    }
    
    myClass.DoAnythingElse();

    даже не скомпилирует.

    Это гораздо лучше, чем минимизировать исключения уже во время компиляции, чем находить их во время выполнения.

    -2
    11.12.2008 16:12:13
    Ваш первый пример не будет компилироваться, это ошибка компиляции, которую вы получите: встроенный оператор не может быть объявлением или помеченным оператором
    mockobject 11.12.2008 16:09:53
    блин, ты прав, компилятор c # достаточно умен для этого.
    Oliver Friedrich 11.12.2008 16:11:33
    Демонстрация того, что C # будет жаловаться согласно комментарию mockobject
    ErrCode 19.09.2018 13:13:38

    Я думаю, что это вопрос руководящих принципов для проекта, над которым вы работаете, и личного вкуса.

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

    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
    }
    23
    11.12.2008 16:05:27

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

    Если вы не очень осторожны при создании макросов, вы можете столкнуться с проблемами в операторах if, которые не используют {}.

    #define BADLY_MADE_MACRO(x) function1(x); function2(x);
    
    if (myCondition) BADLY_MADE_MACRO(myValue)

    Не поймите меня неправильно, я не говорю, что вы всегда должны делать {}, чтобы избежать этой проблемы в C / C ++, но из-за этого мне пришлось столкнуться с некоторыми очень странными ошибками.

    15
    11.12.2008 16:10:55
    если бы весь код объявил себя таковым ... вздох
    Nathan Strong 11.12.2008 23:17:57

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

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

    Если у меня есть одна строка, я обычно форматирую ее следующим образом:

    if( some_condition ) { do_some_operation; }

    Если строка слишком громоздкая, используйте следующее:

    if( some_condition )
    {
        do_some_operation;
    }
    3
    11.12.2008 16:14:24

    Хорошо, мне всегда казалось, что это больше личного предпочтения для меня. Однако я заметил, что для удобства чтения лучше иметь {}, чем не иметь их. Я заметил, используя ReSharper, что ReSharper стремится удалить их и делает большинство из вас, если подобные заявления

    if(this == yes)
          DoSomething();

    Но для удобства чтения я всегда делаю

    if(this == yes)
    {
     DoSomething();
    }

    Хотя с одной строкой кода в операторе «if» читаемость не очень отличается, но если вы поместите 20-30 строк кода в одну инструкцию if, тогда там легче читать с {}, и это оставляет меньше места для ошибок и ошибки в вашем коде.

    0
    11.12.2008 16:18:34

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

    Еще одна веская причина для того, чтобы всегда использовать фигурные скобки, кроме того, что кто-то добавляет второе выражение в if, может происходить примерно так:

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

    Заметили ли вы, что предложение else на самом деле относится к выражению if (b)? Вы, вероятно, сделали, но вы бы доверяли кому-либо, чтобы быть знакомым с этим Гоча?

    Итак, если только для согласованности и потому, что вы никогда не знаете, какие неожиданные вещи могут произойти, когда кто-то другой (это всегда глупые люди) изменяет код, я всегда ставлю фигурные скобки, потому что это делает исходный код более читабельным, быстрее обрабатывает твой мозг. Только для самых простых операторов if, например, если делегирование выполняется или является переключаемым, когда вы знаете, что предложение никогда не будет расширено, я бы оставил скобки.

    47
    11.12.2008 16:22:16
    Это один из двух случаев, когда я использую фигурные скобки. В противном случае нет.
    Andrei Rînea 17.12.2008 01:56:06
    Это должно быть написано так, как будто (a && b) ... во-первых, метинкс.
    alexander.biskop 20.02.2013 10:55:07
    @ alexander.biskop: Конечно, нет, так как это дает блоку else другое значение ( !a || !b), чем с ( !a) или без ( a && !b) добавленных скобок.
    Ben Voigt 30.07.2013 18:47:47
    @ Бен Фойгт: Правда! За это ;-) Полгода и два возражения спустя, кто-то понимает, что сделанное мной заявление неверно ... Думаю, я не уделял достаточно внимания деталям, главным образом потому, что намерение, стоящее за моим комментарием, было иным, чем указание технически правильное преобразование этого if-предложения. Я имел в виду, что вложенные встроенные операторы if, как правило, значительно снижают читабельность (и, в особенности, отслеживаемость потока управления), и, следовательно, их лучше объединять в один оператор (или обходить вообще). Приветствия
    alexander.biskop 30.07.2013 19:39:07
    @ alexander.biskop: в то же время отладка проще с помощью вложенных if-ов, каждый из которых имеет более простые условия, поскольку вы можете перейти на каждый шаг.
    Ben Voigt 30.07.2013 19:42:58

    Задумывались ли вы об изучении этой опции для однострочного оператора if else:

    (!a) ? Foo() : Bar();
    -1
    16.12.2010 17:31:22
    Некоторым это неприятно, потому что троичный оператор предназначен для вычисления значений. Контроль потока в вашем примере является побочным эффектом.
    recursive 11.12.2008 16:51:57
    @ рекурсивный - ты прав. Похоже, что это обычная практика для расчета стоимости: en.wikipedia.org/wiki/%3F :
    Michael Kniskern 11.12.2008 17:07:44

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

    Некоторые могут сказать, что это случай предпочтения, но я считаю, что логический ход программы намного легче следовать, если она внутренне согласована, и я не верю, что согласованно написать одно выражение IF, подобное этому;

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

    И другой, как это;

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

    Я предпочитаю просто выбрать один общий стиль и придерживаться его :)

    8
    11.12.2008 16:40:24

    Я всегда растерялся, когда вижу, что «этот стиль экономит пространство».
    Поскольку я редко, если вообще когда-либо, печатаю код, выигрыш места не имеет для меня очевидного преимущества: сохранение некоторых байтов на диске не стоит, и я не плачу за место, занятое на экране.
    Некоторые люди находят компактный код более читабельным, я не буду спорить (очень субъективно), но как художник-любитель и типограф, я высоко ценю использование пробелов ...

    Я не буду повторять приведенные выше аргументы, но я добавлю, я думаю, согласованность: мне не нравится код вроде

    if (foo)
    {
      // Lot of code
    }
    else
      DoStuff();

    Сказав это, иногда я балуюсь никакими скобками: в условиях охраны, когда я делаю ранний выход:

    if (somethingBadHappened)
      return;

    Подводя итог, я думаю, что добавление (почти) систематических скобок вокруг значимого кода улучшает удобочитаемость (код «дышит», не ограничен), согласованность и может избежать некоторых глупых ошибок (да, такая ошибка очевидна, но кодер - человек (в общем), может быть уставшим, новичком, под стрессом ...).

    Я сделал макрос Lua для SciTE, чтобы добавить эти скобки вокруг любого блока кода или текущей строки одним нажатием клавиши и правильным отступом: для меня это действительно ничего не стоит.

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

    0
    11.12.2008 16:40:26
    «Я не плачу за место на экране». Вы платите за это, не имея возможности видеть другой код одновременно.
    recursive 11.12.2008 16:52:53

    Сокращение строк не очень хороший аргумент для удаления скобок. Если ваш метод слишком велик, его, вероятно, следует реорганизовать в более мелкие части или реструктурировать. Это, несомненно, повысит читабельность, а не просто снимает скобки.

    6
    11.12.2008 16:44:13

    Линии дешевые. Мощность процессора дешевая. Время разработчика очень дорого.

    Как правило, если я не разрабатываю какое-либо абсолютно критичное к ресурсам и скорости приложение, я всегда ошибался бы при написании кода, который

    (a) Легко для любого другого разработчика следить за тем, что я делаю

    (б) Прокомментируйте конкретные части кода, которые могут понадобиться

    (c) Легко отлаживать, если что-то идет не так

    (d) Легко изменить, если это необходимо в будущем (например, добавление / удаление кода)

    Скорость или академическая элегантность кода являются вторичными по отношению к этим факторам с точки зрения бизнеса. Это не значит, что я решил написать неуклюжий или уродливый код, но это МОЙ порядок приоритетов.

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

    35
    11.12.2008 16:47:02
    Ваше последнее утверждение о (а) - это мнение, что большое количество разработчиков, включая другие постеры здесь, будут спорить.
    Kelly S. French 7.08.2012 15:35:00