Моя ошибка, я неверно акцентировал внимание в ответах. В некоторых случаях множественный return уместен. И я пишу его там, где он уместен. Но! Любое ветвление, цикл, или простихоспади рекурсия, усложняют код. Разумеется без условных операторов и циклов вменяемое и читабельное приложение не построить. Однако если есть возможность уменьшить нелинейность кода без ущерба читабельности, стоит это сделать. Как по мне, на первом месте (после функциональности конечно) читабельность, второе - производительность. А уж потом все остальное.
IDE умеет подсвечивать синтаксис уже не один десяток лет, а нелепые ошибки все еще встречаются. За практику повидал и ошибки из-за незамеченного ретурна и пропущенные break и присваивание вместо сравнения. А ведь все это в редакторах подсвечивается. Так что и тебе удачи и не встречать всех этих багов! А, да, и не кодить в vim c чужой машины или телефона, потому что "срочнопиздецвсемухана".
Аргумент "подсвечивается в IDE" вот вообще не аргумент. Во-первых, всегда может оказаться, что правка сделана в окружении, где нет IDE. Во-вторых, даже выделенный другим цветом return может затерятся в ряде других выделеных ключевых слов в той же IDE. А пригорание от множественных return у меня как раз от сопровождения кода с большими простынями методов. А отрефакторить такие методы не всегда удается по разным причинам от "мегасрочная правка" до "метод настолько охренительно сложно-связано-составлен и содержит статические зависимости, что разбить его без unit-тестов опасно, а покрыть тестами - невозможно".
Вообще заметить целую кучу ошибок - не проблема. Однако ж! А по сабжу, старина МакКоннел по поводу заметных ретурнов с тобой не согласен. Хоть он не настаивает на безусловном соблюдении принципа "один вход, один выход", но рекомендует.
Выглядит логично только для случая, когда метод состоит из 3-4 строк. Тогда да return уместен. Но если говорить про методы - "фигня1,2,3, а теперь давай к сути", то метод не охватывается взглядом и можно не заметить return, который изменяет ход выполнения. Для таких случаев рулит принцип модульности "один вход, один выход".
В некоторых случаях множественный return уместен. И я пишу его там, где он уместен.
Но! Любое ветвление, цикл, или простихоспади рекурсия, усложняют код. Разумеется без условных операторов и циклов вменяемое и читабельное приложение не построить. Однако если есть возможность уменьшить нелинейность кода без ущерба читабельности, стоит это сделать.
Как по мне, на первом месте (после функциональности конечно) читабельность, второе - производительность. А уж потом все остальное.
Так что и тебе удачи и не встречать всех этих багов! А, да, и не кодить в vim c чужой машины или телефона, потому что "срочнопиздецвсемухана".
А пригорание от множественных return у меня как раз от сопровождения кода с большими простынями методов. А отрефакторить такие методы не всегда удается по разным причинам от "мегасрочная правка" до "метод настолько охренительно сложно-связано-составлен и содержит статические зависимости, что разбить его без unit-тестов опасно, а покрыть тестами - невозможно".
Но если говорить про методы - "фигня1,2,3, а теперь давай к сути", то метод не охватывается взглядом и можно не заметить return, который изменяет ход выполнения. Для таких случаев рулит принцип модульности "один вход, один выход".
А тем более однострочное условие, когда return не всегда и заметишь на первый взгляд.
Исследования в источниках.
Слушай, а тебе не кажется странным нести ответственность за то, что ты не можешь решить?
С остальным согласен.