Иногда помеченный разрыв или продолжение может сделать код намного более читабельным.
OUTERLOOP: for ( ;/*stuff*/; ) {
//...lots of code
if ( isEnough() ) break OUTERLOOP;
//...more code
}
Мне было интересно, каково общее соглашение для лейблов. Все заглавные буквы? первая шапка?
Если вы должны использовать их, используйте заглавные буквы, это привлекает к ним внимание и выделяет их из-за того, что они ошибочно интерпретируются как «классовые» имена. Привлечение внимания к ним имеет дополнительное преимущество, так как привлекает к себе внимание, а также реорганизует ваш код и удаляет их. ;)
Соглашение состоит в том, чтобы вообще избегать меток.
Существует очень и очень мало веских причин использовать метку для выхода из цикла. Вырваться - это нормально, но вы можете полностью избавиться от необходимости ломаться, немного изменив свой дизайн. В приведенном вами примере вы извлекли бы разделы «Много кода» и поместили их в отдельные методы со значимыми именами.
for ( ;/*stuff*/; )
{
lotsOfCode();
if ( !isEnough() )
{
moreCode();
}
}
Изменить: увидев реальный код ( здесь ), я думаю, использование меток, вероятно, лучший способ сделать код читаемым. В большинстве случаев использование меток является неправильным подходом, в этом случае я думаю, что это нормально.
Конвекция / передовой опыт по-прежнему заключаются в том, чтобы вообще не использовать их и не проводить рефакторинг кода, чтобы сделать его более читабельным с использованием извлечения в качестве метода.
Это своего рода Java - не уверен, есть ли в C #. Я никогда не использовал их на практике, я не могу вспомнить случай, когда их избегание не приведет к гораздо более читабельному коду.
Но если вы должны ... я думаю, что все заглавные буквы в порядке. Большинство людей не будут использовать помеченные разрывы, поэтому, когда они увидят код, заглавные буквы выпрыгнут на них и заставят их осознать, что происходит.
Я знаю, я не должен использовать этикетки.
Но предположим, у меня есть некоторый код, который может значительно улучшить читаемость от помеченных разрывов, как мне их отформатировать.
Мо, твоя предпосылка ошибочна. Вопрос не должен быть «как мне их отформатировать?»
Ваш вопрос должен звучать так: «У меня есть код с большим количеством логики внутри циклов - как мне сделать его более читабельным?»
Ответ на этот вопрос состоит в том, чтобы переместить код в отдельные, хорошо названные функции. Тогда вам вообще не нужно маркировать перерывы.
Соглашение, которое я больше всего видел, это просто случай верблюда, как имя метода ...
myLabel:
но я также видел ярлыки с префиксом подчеркивания
_myLabel:
или с лабораторией ...
labSomething:
Возможно, из других ответов вы можете почувствовать, что вам будет трудно найти стандарт кодирования, который говорит что-то, кроме «Не используйте метки». Тогда я полагаю, что ответ заключается в том, что вы должны использовать любой стиль, который имеет для вас смысл, при условии, что он соответствует.
Я не понимаю, откуда берется это правило "не использовать ярлыки". При выполнении нетривиальной логики зацикливания тест на разрыв или продолжение не всегда аккуратен в конце окружающего блока.
outer_loop:
for (...) {
// some code
for (...) {
// some code
if (...)
continue outer_loop;
// more code
}
// more code
}
Да, подобные случаи случаются постоянно. Что люди предлагают вместо этого использовать? Булево условие как это?
for (...) {
// some code
boolean continueOuterLoop = false;
for (...) {
// some code
if (...) {
continueOuterLoop = true;
break;
}
// more code
}
if (continueOuterLoop)
continue;
// more code
}
Тьфу! Рефакторинг его как метода тоже не облегчает:
boolean innerLoop (...) {
for (...) {
// some code
if (...) {
return true;
}
// more code
}
return false;
}
for (...) {
// some code
if (innerLoop(...))
continue;
// more code
}
Конечно, он немного красивее, но он все еще распространяется вокруг лишнего логического выражения. И если внутренний цикл модифицировал локальные переменные, рефакторинг его в метод не всегда является правильным решением.
Так почему вы все против лейблов? Дайте мне несколько веских причин и практических альтернатив для вышеупомянутого случая.
WRT пример кода Сэди :
Ты дал
outerloop:
for (...) {
// some code
for (...) {
// some code
if (...)
continue outerloop;
// more code
}
// more code
}
В качестве примера. Ты делаешь доброе дело. Мое лучшее предположение будет:
public void lookMumNoLabels() {
for (...) {
// some code
doMoreInnerCodeLogic(...);
}
}
private void doMoreInnerCodeLogic(...) {
for (...) {
// some code
if (...) return;
}
}
Но могут быть примеры, когда такой рефакторинг не соответствует вашей логике.
Поскольку ярлыки настолько редко бывают полезными, кажется, что нет четкого соглашения. Спецификация языка Java имеет один пример с метками, и они находятся в non_cap.
Но поскольку они настолько редки, на мой взгляд, лучше дважды подумать, действительно ли они являются правильным инструментом.
И если они являются правильным инструментом, сделайте их все заглавными, чтобы другие разработчики (или вы сами позже) сразу осознали их как нечто необычное. (как уже указывал Крейг)
Стиль Java-кода Sun, похоже, предпочитает именовать метки так же, как переменные, то есть верблюжий регистр с первой буквой в нижнем регистре.
test
в качестве примера метку, и ясно, что это не прописными буквами (хотя вопрос о том, должен ли он быть указанcamelCase
иunderscored_lower_case
т. Д., Является скорее открытым вопросом).