Раньше я любил читать исследовательские работы по сборке мусора (сейчас я чувствую себя намного лучше, спасибо, что спросил). Общим для них было: «Эти алгоритмы были бы быстрее / выполнимыми, если бы у нас была аппаратная поддержка барьеров записи».
В GC существует проблема блокировки чтения-записи. Вы не можете понять, что за фигня, если приложение продолжает перемещать указатели, пока вы пытаетесь провести инвентаризацию. Один трюк, который люди пробовали снова и снова, - это изменение способа написания указателей для отслеживания изменений. Это называется барьером записи, потому что вы не можете писать без ведения бухгалтерии. Это позволяет одновременно запускать приложение и сборщик мусора, но во многих случаях оказалось, что приложение работает слишком медленно.
Intel пришлось решить аналогичную проблему защиты от записи, чтобы виртуализация работала гладко - как запустить приложение, которое выполняет виртуальную память, в операционной системе, в которой уже есть виртуальная память? По сообщениям, Zing использует эти функции для превращения JVM в буквальную виртуальную машину и использует эти возможности для ускорения работы GC. Чем быстрее GC, тем больше куча, с которой вы можете справиться.
Вам не нужно ни одного перерыва, но они не вредны. На мой взгляд, чтобы сохранить структуру кода, стоит иметь пару посторонних утверждений.
Я согласен с перерывом в последнем случае по умолчанию и не согласен с перерывами после возвратов. (Коллега делает это, и это повреждает мои глаза.)
Я также делаю отступы переключателей, чтобы уменьшить увеличение уровней отступов. :) то есть:
switch(option) {
case 1:
a = 1;
b = 7;
break;
case 2:
a = 2;
b = 4;
return -1;
default:
a = -1;
break;
}
(я также думаю, что, поскольку оператор return не является функцией, неуместно применять лишний стиль, который делает его похожим на один)
Я бы посчитал перерыв после возврата плохим тоном, вы получите предупреждения о недоступности кода на некоторых компиляторах.
Перерыв в вашем случае по умолчанию полностью уместен, случай провала - инструмент и должен быть особо отмечен при использовании.
Разрыв после вашего случая по умолчанию - это просто вопрос личных предпочтений.
Размещение паузы после возврата почти кажется мне противоречивым. Я бы удалил разрыв, просто чтобы оператор return действительно выделялся.
Я предпочитаю всегда иметь перерыв в каждом случае , включая значение по умолчанию , и вообще избегать возврата внутри переключателя . Для коротких переключателей всего с 2-3 случаями (включая значение по умолчанию) return подходит, но только если все case делают это одинаково. «Бессмысленный» перерыв я считаю бессмысленным и просто заставляю читать больше кода. То же самое и с пустыми значениями по умолчанию, которые просто ломаются, совершенно бессмысленно. На мой взгляд, легкость чтения кода важнее того, что произойдет, если кто-то изменит то или это.
Ни один из перерывов не делает ничего для вас, но ни один из них не навредит.
Лично я обычно не использую их, если у меня есть возврат, но я также стараюсь избегать нескольких если возможно, вернуть точки в функции.
Тем не менее, я считаю, что перерыв в регистре default:
хорош - по одной причине: если вы его оставили, и кто-то добавил новый регистр после по умолчанию :,
Как отмечали другие, размещение перерыва после возврата или в случае по умолчанию в основном является вопросом личного стиля.
Когда мне не нужно следовать каким-либо конкретным правилам стиля , Я предпочитаю что-то вроде этого:
switch(foo){ case 0: baz = 1; break; case 1: bar %= 2; return -1; /* NOTREACHED */ case 2: bar = -1; return -2; /* NOTREACHED */ break; default: break; }
Между случаями 1 и 2 я предпочитаю 2. Несмотря на то, что в комментарии написано NOTREACHED, комментарии могут лгать (конечно, непреднамеренно) при изменении кода. Мне нравится комментарий NOTREACHED, поскольку он может удовлетворить lint, что вы знаете, что делаете, и служит напоминанием о том, что вы выходите из функции раньше. Рассуждения о том, что размещение перерыва после возврата уменьшит количество ошибок, если возврат будет удален, мне кажутся ошибочными. Вы по-прежнему будете вести себя фальшиво, независимо от того, перейдете ли вы к следующему делу или выйдете из переключателя и продолжите как раньше.
Конечно, если бы я мог этого избежать, я бы не возвращался из функции в теле переключателя.
Что касается комментария, сделанного другими, что они оставляют перерыв в регистре по умолчанию на случай, если кто-то придет позже и добавит случай после него: Где я работаю, стандарт кодирования говорит always ставит значение по умолчанию в качестве последнего случая; так что в нашей ситуации перерыв в этом случае просто излишен. (Это тот случай, когда я полностью согласен со стандартом кодирования компании, потому что, поскольку кейс по умолчанию всегда является последним, вы всегда знаете, где его найти, даже в длинном операторе switch.)
Что касается перерывов после возвращается, я стараюсь опускать перерыв, если нет каких-либо путей выполнения, которые не возвращаются, поскольку я считаю его избыточным. (Мое исключение составляют те редкие случаи, когда в кейсе несколько путей выполнения, и я могу '
Мне сказали, что в C, C ++, java и C #, если вы не поставите эти «паузы», поток программного кода попадет в другие «случаи» и выполнит инструкции внутри них, независимо от того, не имеет ли переменная значений, присвоенных «наблюдениям».
Я лично не вставляю паузы, но он может помочь, когда кто-то другой решит переместить возврат (-1) в вне переключателя и забывает добавить перерыв.
Я бы сделал перерыв, чтобы показать, что вы не собираетесь переходить к следующему делу.
In this exact example, for both questions, it is personal preference. In general, the rule is this: anything without a break will fall through. That means (as Pod said) its a good idea to put breaks in default cases in case they are not last. This also means if your case contains a return, then a following break is indeed not necessary.
Извините, пожалуйста, за мои ограниченные знания, но что такое ОКР?
Кроме того, Брайан Керниган дает хорошее объяснение того, когда вы должны (не) использовать break
в операторе switch
.