Это нормально, если я опускаю фигурные скобки на Java?

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

Во всяком случае, мой вопрос заключается в важности наличия скобок? Это нормально, если я их опускаю? Пример:

for (int i = 0; i < size; i++)  {
   a += b;
}

против

for (int i = 0; i < size; i++)
   a += b;

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

Ответ 1

Это ничего не изменит, кроме ремонтопригодности вашего кода. Я видел такой код:

for (int i = 0; i < size; i++)
   a += b;
   System.out.println("foo");

что означает следующее:

for (int i = 0; i < size; i++)
   a += b;
System.out.println("foo");

... но должно было быть так:

for (int i = 0; i < size; i++) {
   a += b;
   System.out.println("foo");
}

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

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

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

Ответ 2

Использование фигурных скобок делает код более удобным и понятным. Поэтому вы должны учитывать их по умолчанию.

Я иногда пропускаю с помощью фигурных скобок на сторожевые предложения, чтобы сделать код более компактным. Мое требование для этого состоит в том, что они являются операторами if, за которыми следует инструкция перехода, например return или throw. Кроме того, я держу их в одной строке, чтобы привлечь внимание к идиоме, например:.

if (!isActive()) return;

Они также применимы к внутренним циклам кода:

for (...) {
  if (shouldSkip()) continue;
  ...
}

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

Некоторые языки (например, Perl или Ruby) имеют своего рода условное выражение, где фигурные скобки не применяются:

return if (!isActive());
// or, more interestingly
return unless (isActive());

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

Ответ 3

Нет никакой разницы. Основная проблема со второй версией заключается в том, что вы можете написать это:

for (...) 
  do_something();
  do_something_else();

когда вы обновляете этот метод, думая, что do_something_else() вызывается внутри цикла. (И это приводит к сеансам отладки головок.)

Существует вторая проблема, которая отсутствует в версии скобки, и ее, возможно, еще труднее определить:

for (int i=0; i<3; i++);
  System.out.println("Why on earth does this print just once?");

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

Ответ 4

Я не вижу смысла соглашения.

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

если Oracle решает, что "хорошая практика" всегда пишет if-statement с фигурными скобками, то почему бы им просто не изменить синтаксис?

Мое мнение:

Если я напишу "без оператора фигурных скобок", я всегда помещаю его в одну строку. Положите в две строки такой тип кода странно:

if(statement)
  code; // weird and ugly for me.

if(statement) code; // ok for me, I often use in very short codes.
                    // but if the code is long, so I prefer the code below.

if(statement) {
  code; // if this makes your code clear, then ok.
        // But there is cases when I think the second option is better.
}

Мне не нравятся соглашения, основанные на таких глупых причинах.

Добавлено: многие люди в этом сообщении согласились на одно и то же: вы должны сделать это, чтобы улучшить удобочитаемость. Но я думаю, что делать это, чтобы избежать ошибок, не нужно.

Считаете ли вы, что измените такой код:

while(statement) {
    if (condition) i++;
}

в это:

while(statement) {
    if (condition) {
        i++;
    }
}

улучшит читаемость? Я так не думаю. Это может быть более сложным if-statement. Но все, кого я знаю, кодируют таким образом только в простых if-утверждениях. Правда, первый случай выглядит более ясным.

Но кто-то думает, что для программиста есть возможность сделать это:

while (statement) {
    if (condition) i++;
    statement;
}

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

Я думаю, что следует избегать - писать без брекетов if-statement в двух строках:

while (statement) {
    if (condition)
        i++;
    statement;
}

или гнездо расцепляет выражения вроде:

while (statement)
    if (condition)
        i++;

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

Ответ 5

Если у вас есть один оператор, вы можете опустить скобки, поскольку для объявления блока кода требуется больше одной скобки операторов.

Когда вы используете скобки, вы объявляете блок кода:

{

//Block of code
}

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

for( ; ; )
  if(a == b) 
    doSomething()

он более читаем, записывая с помощью скобок, если это не необходимо:

for( ; ; ) {
  if(a == b) {
    doSomething()
   }
}

Ответ 6

Если вы используете скобки, ваш код более читабельен. И если вам нужно добавить какой-либо оператор в том же блоке, вы можете избежать возможных ошибок.

Ответ 7

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

Говорить, что оставить фигурные скобки плохими, странно или нечитаемо, просто неправильно, поскольку весь язык основан на этой идее, и он довольно популярен (python).

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

Ответ 8

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

Ответ 9

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

if( "Prod".equals(stage) )
  callBankFunction ( creditCardInput )
else
  callMockBankFunction ( creditCardInput )

Теперь скажем, что этот код не работает из-за некоторой внутренней проблемы. Вы хотите проверить ввод. Поэтому вы делаете следующее изменение:

if( "Prod".equals(stage) )
  callBankFunction ( creditCardInput )
else
  callMockBankFunction ( creditCardInput )
  Logger.log( creditCardInput )

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

Таким образом, отсутствие привязки и немного неосторожного кодирования часто может привести к нарушению защищенной информации. Он также классифицируется как уязвимость в JAVA CERT - Software Engineering Institure, CMU.

Ответ 10

Больше поддержки группы "всегда подтяжки" от меня. Если вы опускаете фигурные скобки для циклов/ветвей одного оператора, поместите оператор в ту же строку, что и оператор управления,

if (condition) doSomething();
for(int i = 0; i < arr.length; ++i) arr[i] += b;

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

Ответ 11

Результат мудрый, это то же самое.

Рассматривать только две вещи.

- Поддержание работоспособности кода
 - Свободно связанный код. (может выполняться  что-то другое. потому что вы не указали область действия цикла. )

Примечание. В моем наблюдении, если это цикл с петлей. Внутренняя петля без брекетов также безопасна. Результат не изменится.

Ответ 12

Если вы удалите фигурные скобки, он будет читать только первую строку инструкции. Любые дополнительные строки не будут прочитаны. Если у вас есть более одной строки инструкции для выполнения PLS, используйте фигурные скобки - иначе будет выведено исключение.

Ответ 13

Если у вас есть только один оператор внутри цикла, он будет таким же.

Например, см. следующий код:

for(int i=0;i<4;i++)
            System.out.println("shiva");

в приведенном выше коде есть только одно утверждение. поэтому никаких проблем

for(int i=0;i<4;i++)
            System.out.println("shiva");
            System.out.println("End");

Здесь мы имеем два оператора, но только первый оператор входит внутрь цикла, но не второй оператор.

Если у вас несколько операторов в одном цикле, вы должны использовать фигурные скобки.

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

В настоящее время очень легко перерисовать коды, чтобы узнать, какой блок кодов находится в if или for/while. Если вы настаиваете на том, что повторное отступы трудно выполнить, скобки, помещенные в неправильном углублении, могут смутить вас в равной степени.

for(int i = 0; i < 100; i++) { if(i < 10) {
    doSomething();
} else { for(int j = 0; j < 5; j++) {
        doSomethingElse();
    }
}}

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

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

Если вы хотите утверждать, что предыдущий пример слишком фальшивый/преднамеренный, и что в скобках есть проблема с небрежным отступом (особенно при копировании/вставке кодов), рассмотрите это:

for(int i = 0; i < 100; i++) {
    if(i < 10) {
    doSomething();
}
else {
    for(int j = 0; j < 5; j++) {
        doSomethingElse();
    }
}

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

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