Чтобы ответить на ваш вопрос, нет никакой веской причины иметь что-то, что ничего не делает. Подумайте об этом так: комментарий после return
вместо break
, говорящий «не забывайте», будет иметь тот же эффект - ни один. И говоря так, это звучит глупо, верно?
Если вам не нужно устанавливать переменную для последующего использования, я бы посоветовал подход, который у вас есть, вполне подойдет. Я знал намерение кода в течение 2 секунд после его просмотра. Наличие break
просто создает путаницу.
Нет единого размера, который подходит всем. Правильный подход зависит от того, что соответствует сценарию. Установите переменную в каждом case
, и наличие break
может быть правильным способом, или, возможно, просто возврат имеет смысл.
Некоторые замечания по другим предложениям, высказанным в ответах:
1) Отсутствие break
после return
означает, что могут возникнуть проблемы при последующем изменении кода
Когда это возможно, код должен быть явным, а также читаемым и понятным. Мы также можем кодировать таким образом, чтобы облегчить будущие изменения. Но в таких простых вещах, как switch
, проблем не должно быть, и не требуется никакой сети безопасности для рефакторинга case
позже, чтобы добавить или удалить return
или break
.
На самом деле, если вы удалили return
и " не заметили, что не было break
", то это плохая ошибка, и ее можно допустить в любой части кода. Никакая проверка не поможет вам от этого. И нужно очень тщательно кодировать будущие потенциалы, так как этот потенциал может никогда не произойти, или может произойти что-то еще, и вы просто в конечном итоге будете поддерживать устаревший код годами.
В том же духе это считалось защитной сеткой для будущих изменений. Что если вы удалите return
и случайно оставите в этой защитной сети break
, когда вы должны были удалить его?
Даже если бы этот оператор switch был сценарием жизни или смерти, действительно серьезного кода, я был бы против добавления «бессмысленного» разрыва после возврата. Просто убедитесь, что тот, кто работал над кодом, знал, что делает, и этот код был проверен достаточным количеством глаз и полностью протестирован.
Если бы это было настолько серьезно, то у вас были бы дополнительные проверки лучше, чем предлагаемая сеть безопасности, чтобы поймать неаккуратных разработчиков.
Утверждение, что перерыв после возврата добавляет защитную сеть, означает, что вы не пишете код или тестируете должным образом. Если эта сеть безопасности считается полезной, то, вероятно, в коде есть множество ошибок в потенциально более серьезных местах.
Ссылка на вики-статью "Защитное программирование" была приведена, но здесь она не актуальна:
Защитное программирование - это форма защитного замысла, призванная обеспечить
продолжающаяся функция программного обеспечения в непредвиденных случаях
обстоятельства.
Выход из системы безопасности break
- это не сценарий непредвиденных обстоятельств и не защитное программирование. Это просто плохое кодирование, , и вы не можете засорять свой код резервным кодом на тот случай, если вы неправильно закодируете, когда что-то измените . Это такой плохой подход к кодированию. Аргумент, что «если кто-то удалил, вернет, это не сработает», хорошо, вы можете также опечатку в регистре var, или забыть написать регистр, или ...
Возвращается return
, и вы не кодируете «оборонительно», чтобы избежать сбоя возврата. Это означало бы, что PHP сломан, и вы не будете заполнять свой код сетями безопасности, чтобы удовлетворить это. Это то, что вы имеете на гораздо более высоком уровне.
2) break
после return
сохраняет его в явном виде
Но это явно неправильно. return
возвращается, поэтому перерыва не произойдет. Для меня это время для размышлений, когда я задаюсь вопросом, пропустил ли я намерение - ненадолго, пока ясно, что произойдет , но будет момент, когда я обдумаю это, чтобы убедиться, что я не пропустил что-то.
Хотя не является недействительным или ошибкой иметь return
, а затем break
в том же case
, это просто совершенно бессмысленно, поскольку break
ничего не делает. Это бессмысленный код, который нужно видеть, поддерживать и понимать, поскольку он не логичен.
Если явное является основной целью и с break
после того, как return
попросит вас, потому что это бессмысленно, то я бы сказал, что было бы лучше установить переменную и break
, затем верните переменную после отключения от переключателя.
Мне нравится @RageZ ответ https://stackoverflow.com/a/1437476/2632129
3) Установить переменную и вернуться после завершения оператора switch
В этом подходе нет ничего плохого, но если нет причины хранить значение в переменной (позднее использовать и т. Д.), То лучше сразу вернуться, когда нет необходимости зависать, чтобы делать что-то еще.
Это показывает ясное намерение - вернуть значение, как только будет сопоставлен регистр.