Ящики переключения Java: с или без брекетов?

Рассмотрим следующие два фрагмента с фигурными скобками:

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

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

ОТВЕТЫ

Ответ 1

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

Отсутствует.

Здесь фигурные фигурные скобки помогают компилятору определить область действия переменной, условие, объявление функции и т.д. Это не влияет на производительность выполнения, как только код скомпилирован в исполняемый файл.

Ответ 2

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

Ответ 3

Отсутствие штрафа за исполнение с точки зрения исполнения.

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

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

Ответ 4

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

Открывающая скобка обычно связана с чем-то значимым, как начало функции или начало цикла или начало объявления класса или начало инициализации массива и т.д. Мы знаем, что случай вырывается из блока переключателей, когда он встречает оператор break. Таким образом, использование фигурных скобок, по-видимому, подразумевает идею разного масштаба для случая невежественному читателю. Таким образом, лучше избегать использования фигурных скобок для лучшей читаемости.

то есть. Когда у меня есть что-то вроде

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

  case 2: 
  ....
}

"Привет от 1" печатается. Но использование фигурной скобки может предложить невежественному читателю, что дело заканчивается на "}", уже зная, какие фигурные скобки обычно означают в случае циклов, методов и т.д.

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

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

Мое предложение: просто избегайте использования внешних скобок для корпусов коммутаторов.

Ответ 5

С брекетами.

Есть так много вещей, которые могут пойти не так с операторами switch. Я стараюсь избегать их, где могу, т.е.

  • Забывание разрывов и, таким образом, проваливание случаев
  • Забыть случай по умолчанию и, таким образом, не улавливать условие без обслуживания
  • Случайное повторное использование переменных между утверждениями case или, что еще хуже, влияет на переменную, которая разделяет переменную между аргументами case.

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

Ответ 6

Этот вопрос, вероятно, будет закрыт как "спорный" (BRACE WAR!), но что за черт. Мне действительно нравятся брекеты после случаев. Для меня это делает уродливый синтаксис переключателя более похожим на остальные языковые конструкции. (Нет штрафа за использование фигурных скобок в этом "случае" )

Ответ 7

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

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

Ответ 8

Я бы не использовал фигурные скобки для корпусов коммутаторов.

  • Оператор switch выглядит уже без барокко уже без брекетов.

  • Случаи переключения должны быть очень короткими. Когда вам нужно объявлять переменные, это признак того, что вы делаете это неправильно.

Теперь вы можете сохранить некоторый унаследованный C-код, в котором участвуют спортивные переключатели более 500 строк...

Ответ 9

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

Отсутствие фигурных скобок... меньше синтаксиса больше