Корпуси комутаторів Java: з фігурними дужками чи без них?


85

Розглянемо наступні два фрагменти з фігурними дужками:

switch (var) {
  case FOO: {
    x = x + 1;
    break;
  }

  case BAR: {
    y = y + 1;
    break;
  }
}

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

switch (var) {
  case FOO:
    x = x + 1;
    break;

  case BAR:
    y = y + 1;
    break;
}

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

Відповіді:


99

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

Жоден.

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


21

Відсутність покарання за виконання з точки зору виконання.

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

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


Мені трохи цікаво, оскільки я сам не бачу відповіді ... @TofuBeer, коли ви ТРЕБА додати дужки? Крім того, я повністю погоджуюся з пунктом ремонтопридатності, я просто не бачу проблеми з ремонтопридатністю банкомату. EDIT: неважливо. Я просто прочитав решту відповідей нижче.
нярай

У деяких випадках ви працюєте на C ++, тому, якщо ви працюєте на обох мовах, це не погана звичка входити в обидві.
TofuBeer

13

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

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

тобто коли у мене є щось на зразок,

switch(i)
{
  case 1 :
  {
     //do something
  }
  System.out.println("Hello from 1");

  case 2: 
  ....
}

Друкується "Привіт з 1". Але використання фігурних фігурних дужок може підказати необізнаному читачеві, що справа закінчується на '}', вже знаючи, що фігурні дужки зазвичай означають у випадку циклів, методів тощо.

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

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

Моя порада: Просто уникайте використання навколишніх брекет-систем для корпусів перемикачів.


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

12

З брекетами.

Існує так багато речей, які можуть піти не так із операторами перемикання, я намагаюся уникати їх там, де можу, тобто

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

Використання фігурних дужок - це один із способів запобігти навмисному та випадковому обміну змінними між операторами регістру


8
Включення пунктів 1 і 2 було оманливим для цього питання (для мене); у вашому закриваючому рядку має бути чітко сказано, що фігурні дужки вирішують лише 3 - я думав, ви мали на увазі, що фігурні дужки виключають необхідність розривів, а потім спробували.
ataulm

Пункт 3 навіть не має сенсу. Ви не можете повторно використовувати змінні, якщо вони не були оголошені в батьківській області дії інструкції switch. Це означає, що якщо ви оголосите змінну в межах справи, тоді вона не може бути використана в іншому випадку. Якщо ви оголосите змінну над оператором switch (у батьківській області), не має значення, використовуєте ви фігурні дужки чи ні, оператори case матимуть доступ до змінної.
dsingleton

Я щойно (повторно) виявив, що змінні, оголошені у випадку 1, все ще можуть бути в зоні дії у випадку 2. Наприклад: ...case 1: int a = 10; break; case 2: int a = 11; break; ...не компілюється. (протестовано за допомогою Oracle JDK 8)
anuragw,

5

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


Думаю, це якесь об’єктивне питання ... Я відкликаю аргументовану річ
Енді Уайт,

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

Так, я би хотів, щоб це було приблизно так: case (FOO) {x = x + 1} case (BAR) {y = y + 1}
Енді Уайт

Розумний пробіл == приємно. Непотрібні брекети == смоктати.
Shog9

3
пробіли == поєднання вкладок та пробілів == смоктати (просто думав, що я вкину в мікс вкладку проти пробілу)
Енді Уайт,

5

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

Брекети насправді є найбільш корисними для того, щоб у підсумку не використовувати caseпомилково ту саму змінну в різних s. Сьогодні вони не оголошують жодних змінних, але хтось додасть їх завтра, і без фігурних дужок код схильний до помилок.


3

Я не використовував би брекети для корпусів комутаторів.

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

  • Корпуси комутаторів повинні бути дуже короткими. Коли вам потрібно оголосити змінні, це знак того, що ви робите це неправильно.

Тепер до підтримки деякого застарілого коду С, який перемикає випадки 500+ рядків ...


1

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

Без фігурних дужок ... менше синтаксису - це більше


{і} також виділяють речі, що полегшує читання (IMO).
TofuBeer,

Так. Я збирався поділитися історією методу, який мені колись довелося модифікувати (на додавання одного рядка коду у мене пішло близько 4 годин), але код був божевільним (близько 10 сторінок довжиною та 4 сторінки шириною при друку), тому він не є типовий випадок. Але якби він використовував {}, то на його додавання знадобилася б хвилина.
TofuBeer

Я думаю, справа тут у тому, що якби оригінальний програміст доклав зусиль до введення блоків {}, щоб код був більш читабельним, вони могли б насправді піклуватися про те, щоб вони, коли писали оператор перемикання на 10 сторінок і змінювали код на трохи менше божевільний
Гарет Девіс

swtich був би мрією .. він був вкладений if / elses ... написаний програмістами COBOL на коді C ++ ... Я незабаром кинув це.
TofuBeer
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.