Це нормально, якщо я опускаю фігурні дужки в Java? [зачинено]

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

У будь-якому випадку, моє питання полягає в тому, що важливо мати дужки? Це нормально, якщо я їх опускаю? Приклад:

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

проти

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

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

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

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");
}

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

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

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

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

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

if (!isActive()) return;

Вони також застосовуються до коду всередині циклів:

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

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

Деякі мови (наприклад, Perl чи Ruby) мають своєрідний умовний вираз , де фігурні дужки не застосовуються:

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

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

Різниці немає. Основною проблемою другої версії є те, що ви в кінцевому підсумку можете написати це:

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?");

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

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

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

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

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

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

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

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

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

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

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

Коли ви використовуєте дужки, ви оголошуєте блок коду:

{

//Block of code
}

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

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

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

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

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

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

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

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

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

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

Результат мудрий, це те саме.

Враховувати лише дві речі.

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

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

Якщо у вас є лише одне твердження всередині циклу, це однаково.

Наприклад, див. Наступний код:

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");

Тут ми маємо два оператори, але всередині цикла входить лише перший, але не другий.

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

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

На сьогоднішній день дуже легко зробити відступи кодів, щоб з’ясувати, який блок кодів знаходиться в якому 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, відповідальність за написання коду несе відповідальність за перевірку коду та переконання у правильному відступі речей, перш ніж виконувати інші дії.

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

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