Должна ли функция иметь только один оператор return?
https://stackoverflow.com/questions/36707
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Существуют ли веские причины, по которым лучше использовать только один оператор return в функции?
Или это нормально - возвращаться из функции, как только это логически правильно, что означает, что в функции может быть много операторов return?
Решение
У меня часто есть несколько утверждений в начале метода, который нужно вернуть для "easy" ситуации. Например, это:
public void DoStuff(Foo foo)
{
if (foo != null)
{
...
}
}
... можно сделать более читабельным (ИМХО), например так:
public void DoStuff(Foo foo)
{
if (foo == null) return;
...
}
Да, я думаю, что хорошо иметь несколько " точек выхода " из функции / метода.
Другие советы
Никто не упоминал и не цитировал Code Complete , поэтому я сделаю это.
17,1 возврата
Минимизируйте количество возвратов в каждой подпрограмме . Труднее понять рутину, если, читая ее внизу, вы не подозреваете, что она вернулась где-то выше.
Используйте return , когда это улучшает удобочитаемость . В некоторых подпрограммах, когда вы знаете ответ, вы хотите немедленно вернуть его в вызывающую подпрограмму. Если подпрограмма определена таким образом, что она не требует какой-либо очистки, то немедленный возврат означает, что вам нужно написать больше кода.
Я бы сказал, что было бы невероятно неразумно принимать произвольные решения против нескольких точек выхода, так как я обнаружил, что техника полезна на практике снова и снова , на самом деле я часто рефакторинг существующий код для нескольких точек выхода для ясности. Мы можем сравнить два подхода таким образом: -
string fooBar(string s, int? i) {
string ret = "";
if(!string.IsNullOrEmpty(s) && i != null) {
var res = someFunction(s, i);
bool passed = true;
foreach(var r in res) {
if(!r.Passed) {
passed = false;
break;
}
}
if(passed) {
// Rest of code...
}
}
return ret;
}
Сравните это с кодом, в котором разрешено несколько точек выхода : -
string fooBar(string s, int? i) {
var ret = "";
if(string.IsNullOrEmpty(s) || i == null) return null;
var res = someFunction(s, i);
foreach(var r in res) {
if(!r.Passed) return null;
}
// Rest of code...
return ret;
}
Я думаю, что последнее значительно яснее. Насколько я могу судить, критика нескольких точек выхода в наши дни довольно архаична.
В настоящее время я работаю над базой кода, где двое из людей, работающих над ней, слепо подписываются на «единую точку выхода». теория, и я могу сказать вам, что из опыта, это ужасно ужасная практика. Это делает код чрезвычайно сложным в обслуживании, и я покажу вам, почему.
С "единой точкой выхода" теория, вы неизбежно получите код, который выглядит следующим образом:
function()
{
HRESULT error = S_OK;
if(SUCCEEDED(Operation1()))
{
if(SUCCEEDED(Operation2()))
{
if(SUCCEEDED(Operation3()))
{
if(SUCCEEDED(Operation4()))
{
}
else
{
error = OPERATION4FAILED;
}
}
else
{
error = OPERATION3FAILED;
}
}
else
{
error = OPERATION2FAILED;
}
}
else
{
error = OPERATION1FAILED;
}
return error;
}
Мало того, что это делает код очень сложным для отслеживания, но теперь скажем, что позже вам нужно вернуться назад и добавить операцию между 1 и 2. Вы должны сделать отступ практически для всей функции офигения и удачи убедитесь, что все ваши условия if / else и скобки соответствуют друг другу.
Этот метод делает обслуживание кода чрезвычайно сложным и подверженным ошибкам.
структурированное программирование говорит, что в каждой функции должен быть только один оператор возврата. Это для ограничения сложности. Многие люди, такие как Мартин Фаулер, утверждают, что проще писать функции с несколькими операторами возврата. Он приводит этот аргумент в классической книге по рефакторингу , которую он написал. Это хорошо работает, если вы будете следовать его другим советам и писать небольшие функции. Я согласен с этой точкой зрения, и только пуристы строгого структурированного программирования придерживаются единственного оператора return для каждой функции.
Как отмечает Кент Бек, обсуждая пункты охраны в Шаблоны реализации , делающие подпрограмму, имеют одну точку входа и выхода ...
было предотвращение путаницы когда прыгает в и из многих места в той же рутине. Это сделано здравый смысл применительно к Фортрану или программы на ассемблере написаны с большим количеством глобальных данных, где даже понимание того, какие заявления были Выполнение было тяжелой работой ... с небольшими методами и в основном локальными данными, это излишне консервативно. "
Я считаю, что функцию, написанную с защитными предложениями, гораздо проще выполнять, чем одну длинную вложенную группу операторов if then else .
В функции, которая не имеет побочных эффектов, нет веской причины иметь более одного возврата, и вы должны написать их в функциональном стиле. В методе с побочными эффектами вещи более последовательны (индексируются по времени), поэтому вы пишете в императивном стиле, используя инструкцию return в качестве команды для прекращения выполнения.
Другими словами, по возможности, поддерживайте этот стиль
return a > 0 ?
positively(a):
negatively(a);
над этим
if (a > 0)
return positively(a);
else
return negatively(a);
Если вы обнаружите, что пишете несколько слоев вложенных условий, возможно, есть способ реорганизовать это, например, используя список предикатов. Если вы обнаружите, что ваши if и elses синтаксически далеко друг от друга, вы можете разбить это на более мелкие функции. Условный блок, который занимает больше, чем экранный текст, трудно прочитать.
Нет жесткого и быстрого правила, применимого к каждому языку. Что-то вроде наличия одного оператора return не сделает ваш код хорошим. Но хороший код, как правило, позволяет вам писать свои функции таким образом.
Я видел это в стандартах кодирования для C ++, которые представляли собой похмелье от C, так как если у вас нет RAII или другого автоматического управления памятью, вам придется очищать для каждого возврата, что означает либо and-paste для очистки или перехода (логически то же самое, что и «finally» в управляемых языках), оба из которых считаются плохими. Если вы практикуете использование умных указателей и коллекций в C ++ или другой автоматической системе памяти, то для этого нет веских оснований, и все сводится к удобочитаемости и, скорее, к суждению.
Я склоняюсь к мысли, что операторы return в middle функции плохие. Вы можете использовать return для создания нескольких охранных предложений в верхней части функции и, конечно, сообщить компилятору, что возвращать в конце функции без проблем, но возвращает в middle функции может быть легко пропущен и может затруднить интерпретацию функции.
Существуют ли веские причины, по которым лучше использовать только один оператор return в функции?
ДА, существуют:
- Единственная точка выхода предоставляет отличное место для утверждения ваших постусловий.
- Часто бывает полезно установить точку останова отладчика для одного возвращаемого значения в конце функции.
- Меньшее количество возвратов означает меньшую сложность.Линейный код, как правило, проще для понимания.
- Если попытка упростить функцию до одного возвращаемого значения приводит к усложнению, то это стимул к рефакторингу до меньших, более общих, более понятных функций.
- Если вы используете язык без деструкторов или если вы не используете RAII, то один возврат уменьшает количество мест, которые вам нужно очистить.
- Некоторые языки требуют единой точки выхода (например, Pascal и Eiffel).
Этот вопрос часто ставится как ложная дихотомия между несколькими возвратами или глубоко вложенными операторами if.Почти всегда существует третье решение, которое является очень линейным (без глубокой вложенности) и имеет только одну точку выхода.
Обновить:Очевидно Руководящие принципы MISRA способствуют единому выходу, тоже.
Чтобы внести ясность, я не говорю, что это всегда неправильно иметь несколько возвратов.Но, учитывая в остальном эквивалентные решения, есть много веских причин предпочесть решение с единственным возвратом.
Наличие единственной точки выхода дает преимущество в отладке, поскольку позволяет установить одну точку останова в конце функции, чтобы увидеть, какое значение на самом деле будет возвращено.
В общем, я стараюсь иметь только одну точку выхода из функции. Однако бывают случаи, когда это фактически приводит к созданию более сложного тела функции, чем необходимо, и в этом случае лучше иметь несколько точек выхода. Это действительно должен быть «призыв к суждению» на основе полученной сложности, но цель должна состоять в том, чтобы как можно меньше было точек выхода без ущерба для сложности и понятности.
Нет, потому что мы больше не живем в 1970-х годах . Если ваша функция достаточно длинная, чтобы множественные возвраты были проблемой, она слишком длинная.
(Совершенно независимо от того факта, что любая многострочная функция в языке с исключениями в любом случае будет иметь несколько точек выхода.)
Я бы предпочел одиночный выход, если только это действительно не усложнит ситуацию.Я обнаружил, что в некоторых случаях несколько существующих точек могут маскировать другие, более существенные проблемы проектирования:
public void DoStuff(Foo foo)
{
if (foo == null) return;
}
Увидев этот код, я бы сразу спросил:
- Является ли 'foo' когда-либо нулевым?
- Если да, то сколько клиентов 'doStuff' когда-либо вызывали функцию с нулевым значением 'foo'?
В зависимости от ответов на эти вопросы может оказаться, что
- проверка бессмысленна, поскольку она никогда не является истинной (т.е.это должно быть утверждение)
- проверка очень редко оказывается верной, и поэтому, возможно, было бы лучше изменить эти конкретные функции вызывающего абонента, поскольку они, вероятно, в любом случае должны предпринять какие-то другие действия.
В обоих вышеприведенных случаях код, вероятно, может быть переработан с утверждением, чтобы гарантировать, что 'foo' никогда не имеет значения null и соответствующие вызывающие устройства изменены.
Есть две другие причины (специфичные, я думаю, для кода C ++), по которым несколько существующих на самом деле могут иметь отрицательный влиять.Это размер кода и оптимизация компилятора.
Объект C ++, не являющийся POD, в области видимости при выходе из функции будет вызывать свой деструктор.Там, где имеется несколько операторов return , может оказаться, что в области видимости находятся разные объекты, и поэтому список вызываемых деструкторов будет другим.Поэтому компилятору необходимо сгенерировать код для каждого оператора return:
void foo (int i, int j) {
A a;
if (i > 0) {
B b;
return ; // Call dtor for 'b' followed by 'a'
}
if (i == j) {
C c;
B b;
return ; // Call dtor for 'b', 'c' and then 'a'
}
return 'a' // Call dtor for 'a'
}
Если размер кода является проблемой, то, возможно, этого стоит избегать.
Другая проблема связана с "Оптимизацией именованного возвращаемого значения" (aka Copy Elision, ISO C ++ '03 12.8 / 15).C ++ позволяет реализации пропустить вызов конструктора копирования, если это возможно:
A foo () {
A a1;
// do something
return a1;
}
void bar () {
A a2 ( foo() );
}
Просто принимая код как есть, объект 'a1' создается в 'foo', а затем для построения 'a2' будет вызвана конструкция его копии.Однако исключение копирования позволяет компилятору создать 'a1' в том же месте стека, что и 'a2'.Поэтому нет необходимости "копировать" объект, когда функция возвращает результат.
Множественные точки выхода усложняют работу компилятора при попытке обнаружить это, и, по крайней мере, для относительно недавней версии VC ++ оптимизация не проводилась там, где тело функции имело несколько возвратов.Видишь Оптимизация именованных возвращаемых значений в Visual C ++ 2005 для получения более подробной информации.
Наличие единой точки выхода снижает цикломатическую сложность и, следовательно, в теории , уменьшает вероятность того, что вы будете вносить ошибки в свой код при его изменении. Однако практика, как правило, предполагает, что необходим более прагматичный подход. Поэтому я стремлюсь иметь одну точку выхода, но позволяю своему коду иметь несколько, если это более читабельно.
Я заставляю себя использовать только один return оператор, поскольку он в некотором смысле будет генерировать запах кода.Позвольте мне объяснить:
function isCorrect($param1, $param2, $param3) {
$toret = false;
if ($param1 != $param2) {
if ($param1 == ($param3 * 2)) {
if ($param2 == ($param3 / 3)) {
$toret = true;
} else {
$error = 'Error 3';
}
} else {
$error = 'Error 2';
}
} else {
$error = 'Error 1';
}
return $toret;
}
(Условия являются обязательными ...)
Чем больше условий, тем больше становится функция, тем сложнее ее читать.Так что, если вы настроены на запах кода, вы поймете это и захотите провести рефакторинг кода.Двумя возможными решениями являются:
- Многократные возвраты
- Рефакторинг на отдельные функции
Многократные Возвраты
function isCorrect($param1, $param2, $param3) {
if ($param1 == $param2) { $error = 'Error 1'; return false; }
if ($param1 != ($param3 * 2)) { $error = 'Error 2'; return false; }
if ($param2 != ($param3 / 3)) { $error = 'Error 3'; return false; }
return true;
}
Отдельные функции
function isEqual($param1, $param2) {
return $param1 == $param2;
}
function isDouble($param1, $param2) {
return $param1 == ($param2 * 2);
}
function isThird($param1, $param2) {
return $param1 == ($param2 / 3);
}
function isCorrect($param1, $param2, $param3) {
return !isEqual($param1, $param2)
&& isDouble($param1, $param3)
&& isThird($param2, $param3);
}
Конечно, это длиннее и немного запутаннее, но в процессе рефакторинга функции таким образом мы получили
- создал ряд повторно используемых функций,
- сделал функцию более понятной для человека, и
- основное внимание функций уделяется тому, почему значения являются правильными.
Я бы сказал, что у вас должно быть столько, сколько требуется, или любое, которое делает код чище (например, пункты охраны ).
Лично я никогда не слышал / не видел ни одной "наилучшей практики" скажем, что у вас должно быть только одно возвращаемое выражение.
По большей части, я склонен как можно быстрее выходить из функции, основываясь на логическом пути (пункты охраны - отличный пример этого).
Я считаю, что многократные возвраты обычно хороши (в коде, который я пишу на C #).Стиль с одним возвратом является пережитком C.Но вы, вероятно, не кодируете на C.
Во всех языках программирования нет закона, требующего только одной точки выхода для метода.Некоторые люди настаивают на превосходстве этого стиля, а иногда возводят его в ранг "правила" или "закона", но эта вера не подкреплена никакими доказательствами или исследованиями.
Более одного стиля возврата может быть плохой привычкой в коде C, где ресурсы должны быть явно выделены, но такие языки, как Java, C #, Python или JavaScript, которые имеют такие конструкции, как автоматическая сборка мусора и try..finally блоки (и using блоки в C #), и этот аргумент неприменим - в этих языках очень редко требуется централизованное ручное освобождение ресурсов.
Есть случаи, когда одиночный возврат более удобочитаем, и случаи, когда это не так.Посмотрите, уменьшает ли это количество строк кода, делает ли логику более понятной или уменьшает количество фигурных скобок и отступов или временных переменных.
Поэтому используйте столько возвратов, сколько соответствует вашим художественным предпочтениям, поскольку это проблема верстки и удобочитаемости, а не техническая.
Я уже говорил о более подробно об этом читайте в моем блоге.
Есть много хорошего, что можно сказать о наличии единой точки выхода, точно так же, как есть много плохого, что можно сказать о неизбежном "стрела" программирование, которое приводит к результату.
При использовании нескольких точек выхода во время проверки входных данных или распределения ресурсов я стараюсь, чтобы все "выходы с ошибками" были очень заметны в верхней части функции.
Оба Спартанское программирование статья из "SSDSLPedia" и единственная точка выхода функции в статье "Portland Pattern Repository's Wiki" есть несколько убедительных аргументов по этому поводу.Также, конечно, есть этот пост для рассмотрения.
Если вам действительно нужна единственная точка выхода (на любом языке без исключений), например, для того, чтобы высвобождать ресурсы в одном месте, я считаю, что тщательное применение goto будет хорошим;смотрите, например, этот довольно надуманный пример (сжатый для сохранения экранной недвижимости):
int f(int y) {
int value = -1;
void *data = NULL;
if (y < 0)
goto clean;
if ((data = malloc(123)) == NULL)
goto clean;
/* More code */
value = 1;
clean:
free(data);
return value;
}
Лично мне, в общем, не нравится программирование со стрелками больше, чем несколько точек выхода, хотя и то, и другое полезно при правильном применении.Лучше всего, конечно, структурировать вашу программу так, чтобы она не требовала ни того, ни другого.Обычно помогает разбиение вашей функции на несколько частей :)
Хотя при этом я обнаруживаю, что в любом случае получаю несколько точек выхода, как в этом примере, где какая-то более крупная функция была разбита на несколько более мелких функций:
int g(int y) {
value = 0;
if ((value = g0(y, value)) == -1)
return -1;
if ((value = g1(y, value)) == -1)
return -1;
return g2(y, value);
}
В зависимости от проекта или рекомендаций по кодированию большая часть кода котельной плиты может быть заменена макросами.В качестве дополнительного примечания, разбиение его таким образом позволяет очень легко тестировать функции g0, g1, g2 по отдельности.
Очевидно, что на языке OO и с поддержкой исключений я бы не использовал подобные операторы if (или вообще, если бы мне это сходило с рук без особых усилий), и код был бы намного более простым.И без стрел.И большинство не окончательных возвратов, вероятно, были бы исключениями.
Короче говоря;
- Небольшое количество возвратов лучше, чем много возвратов
- Более одного возврата лучше, чем огромные стрелы, и охранительные положения в целом все в порядке.
- Исключения, вероятно, могут / должны заменять большинство "защитных оговорок", когда это возможно.
Вы знаете изречение - красота в глазах смотрящего .
Некоторые люди клянутся NetBeans , а некоторые - IntelliJ IDEA , некоторые от Python и некоторые из них PHP .
В некоторых магазинах вы можете потерять работу, если будете настаивать на этом:
public void hello()
{
if (....)
{
....
}
}
Все дело в наглядности и удобстве обслуживания.
Я пристрастился к использованию булевой алгебры, чтобы уменьшить и упростить логику и использование конечных автоматов. Тем не менее, в прошлом были коллеги, которые верили, что я использую «математические методы». в кодировании это не подходит, потому что он не будет видимым и ремонтопригодным. И это было бы плохой практикой. Извините, люди, которые я использую, очень наглядны и понятны для меня, потому что, когда я вернусь к коду шесть месяцев спустя, я ясно пойму код, скорее увидев беспорядок общеизвестных спагетти.
Эй, приятель (как обычно говорил бывший клиент), делай что хочешь, если знаешь, как это исправить, когда мне нужно, чтобы ты это исправил.
Я помню, 20 лет назад мой коллега был уволен за использование того, что сегодня будет называться гибкой разработки стратегия. У него был дотошный пошаговый план. Но его менеджер кричал на него "Вы не можете постепенно предоставлять функции пользователям! Вы должны придерживаться водопада . & Quot; Он ответил менеджеру, что постепенное развитие будет более точным в соответствии с потребностями клиента. Он верил в разработку для нужд клиентов, но менеджер верил в кодирование для «требований клиента».
Мы часто виновны в нарушении нормализации данных, MVP и границы MVC , Мы встраиваем вместо того, чтобы строить функцию. Мы берем ярлыки.
Лично я считаю, что PHP - плохая практика, но что я знаю. Все теоретические аргументы сводятся к попыткам выполнить один набор правил
качество = точность, ремонтопригодность и рентабельность.
Все остальные правила уходят на второй план. И, конечно, это правило никогда не исчезает:
Лень - добродетель добра программист.
Я склоняюсь к использованию охранных предложений для раннего возврата и иного выхода в конце метода. Единственное правило входа и выхода имеет историческое значение и было особенно полезно при работе с устаревшим кодом, который занимал до 10 страниц А4 для одного метода C ++ с множественными возвратами (и многими дефектами). В последнее время общепринятой практикой является сохранение небольших методов, что делает множественные выходы менее значительными для понимания. В следующем примере Kronoz, скопированном выше, вопрос в том, что происходит в // Остальной части кода ... ?:
void string fooBar(string s, int? i) {
if(string.IsNullOrEmpty(s) || i == null) return null;
var res = someFunction(s, i);
foreach(var r in res) {
if(!r.Passed) return null;
}
// Rest of code...
return ret;
}
Я понимаю, что пример несколько надуманный, но у меня возникнет соблазн реорганизовать цикл foreach в оператор LINQ, который затем можно будет считать предложением защиты. Опять же, в надуманном примере цель кода не очевидна, и у someFunction () может быть какой-то другой побочный эффект, или результат может быть использован в // Остальной части кода .. . .
if (string.IsNullOrEmpty(s) || i == null) return null;
if (someFunction(s, i).Any(r => !r.Passed)) return null;
Предоставление следующей рефакторированной функции:
void string fooBar(string s, int? i) {
if (string.IsNullOrEmpty(s) || i == null) return null;
if (someFunction(s, i).Any(r => !r.Passed)) return null;
// Rest of code...
return ret;
}
Одна хорошая причина, которую я могу придумать, заключается в обслуживании кода: у вас есть единственная точка выхода. Если вы хотите изменить формат результата, ... это гораздо проще реализовать. Кроме того, для отладки вы можете просто прикрепить точку останова:)
Сказав это, мне когда-то приходилось работать в библиотеке, где стандарты кодирования накладывали «один оператор возврата на функцию», и я нашел это довольно сложным. Я пишу много кода для числовых вычислений, и часто бывают «особые случаи», так что в конечном итоге код оказался довольно сложным ...
Несколько точек выхода подходят для достаточно небольших функций, то есть функции, которую можно просматривать на всей длине экрана в целом. Если длинная функция также включает в себя несколько точек выхода, это признак того, что эту функцию можно продолжить.
Тем не менее, я избегаю функций множественного выхода , если это не является абсолютно необходимым . Я чувствовал боль от ошибок, связанных с каким-то случайным возвратом в неясную строку в более сложных функциях.
Я работал с ужасными стандартами кодирования, которые навязывали вам единый путь выхода, и результатом почти всегда были неструктурированные спагетти, если функция не тривиальна - у вас в конечном итоге много перерывов и продолжений, которые просто попадают в путь.
Единая точка выхода - при прочих равных условиях - делает код значительно более читабельным. Но есть подвох: популярная конструкция
resulttype res;
if if if...
return res;
является подделкой, " res = " не намного лучше, чем «возврат». Он имеет один оператор возврата, но несколько точек, где функция фактически заканчивается.
Если у вас есть функция с несколькими возвратами (или " res = " s), часто полезно разбить ее на несколько более мелких функций с одной точкой выхода.
Моя обычная политика - иметь только один оператор return в конце функции, если сложность кода не будет значительно уменьшена путем добавления большего количества. На самом деле, я скорее фанат Eiffel, который применяет единственное правило возврата, не имея оператора return (есть просто автоматически созданная переменная 'result' для помещения вашего результата).
Конечно, есть случаи, когда код можно сделать более понятным с множественными возвратами, чем очевидная версия без них. Можно утверждать, что требуется дополнительная доработка, если у вас есть функция, которая слишком сложна, чтобы ее можно было понять без множественных операторов возврата, но иногда полезно быть прагматичным в таких вещах.
Если вы получили более нескольких возвратов, возможно, что-то не так с вашим кодом. В противном случае я бы согласился, что иногда приятно иметь возможность возвращаться из нескольких мест в подпрограмме, особенно когда это делает код чище.
Perl 6: плохой пример
sub Int_to_String( Int i ){
given( i ){
when 0 { return "zero" }
when 1 { return "one" }
when 2 { return "two" }
when 3 { return "three" }
when 4 { return "four" }
...
default { return undef }
}
}
было бы лучше написать так
Perl 6: хороший пример
@Int_to_String = qw{
zero
one
two
three
four
...
}
sub Int_to_String( Int i ){
return undef if i < 0;
return undef unless i < @Int_to_String.length;
return @Int_to_String[i]
}
Обратите внимание, что это всего лишь быстрый пример
Я голосую за Единственное возвращение в конце как руководство. Это помогает общей очистке кода ... Например, взгляните на следующий код ...
void ProcessMyFile (char *szFileName)
{
FILE *fp = NULL;
char *pbyBuffer = NULL:
do {
fp = fopen (szFileName, "r");
if (NULL == fp) {
break;
}
pbyBuffer = malloc (__SOME__SIZE___);
if (NULL == pbyBuffer) {
break;
}
/*** Do some processing with file ***/
} while (0);
if (pbyBuffer) {
free (pbyBuffer);
}
if (fp) {
fclose (fp);
}
}
Это, вероятно, необычная перспектива, но я думаю, что любому, кто считает, что нужно использовать несколько операторов return, никогда не приходилось использовать отладчик на микропроцессоре, который поддерживает только 4 аппаратных точки останова. ; -)
Пока проблемы с «кодом стрелки» являются полностью правильными, одна проблема, которая, кажется, исчезает при использовании нескольких операторов возврата, в ситуации, когда вы используете отладчик. У вас нет удобной универсальной позиции для установки точки останова, чтобы гарантировать, что вы увидите выход и, следовательно, условие возврата.
Чем больше операторов возврата у вас есть в функции, тем выше сложность этого метода. Если вам интересно, есть ли у вас слишком много возвращаемых операторов, вы можете спросить себя, не слишком ли много строк кода в этой функции.
Но нет, нет ничего плохого в одном / многих операторах возврата. В некоторых языках это лучше (C ++), чем в других (C).
