Только один оператор return для каждого метода, даже в этом сценарии?

StackOverflow https://stackoverflow.com/questions/315546

  •  10-07-2019
  •  | 
  •  

Вопрос

Мне нравится идея иметь только один return оператор для каждого метода.

Но что вы делаете в этой ситуации?

public static string ChopText(string Text)
{
   if (String.IsNullOrEmpty(Text))
   {
      // return here ?????
   }
}

Единственная альтернатива, о которой я могу подумать, - это установка флага, а затем проверка его наличия.

Проблема в том, что мне не нравится иметь огромные инструкции if, которые занимают больше страницы. Я также видел уродливые вложенные операторы if в результате этого.

Это было полезно?

Решение

Можно заменить вложенные условные выражения защитными предложениями .

Другие советы

Честно говоря, в подобных ситуациях чересчур жесткие правила плохие.

Смысл подобных правил состоит в том, чтобы сделать код более читабельным и обслуживаемым, поэтому, когда они затрудняют чтение кода, их следует игнорировать.

Это не означает, что правило должно быть полностью отброшено, потому что в большинстве случаев оно делает код более читабельным.

Код, который пытается получить только один возврат на функцию, гораздо сложнее. Обычно это крысиное гнездо «если-то» и заданий. Я призываю вас взглянуть на такой код и узнать, что правильное значение всегда возвращается из этих разных путей. Ни за что.

Сказав это, большие функции указывают на то, что вам, возможно, потребуется реорганизовать код в меньшие более простые функции.

Лично я думаю 

public static string ChopText(string Text))
{
   if(String.IsNullOrEmpty(Text)
      return Text;

   ...
}

совершенно нормально, если вам не нравятся эти и если они становятся большими.

"Мне нравится идея иметь только 1 оператор return для каждого метода". Объяснить?

Как только вы узнаете, что параметры, переданные вашему методу, недопустимы, вы должны вернуть или выдать исключение.

Плохой:

if (Valid) { do lots of stuff}
else {return};

Чистый:

if (invalid) { return; }
if (invalid2) {return; }

Другой подход:

if (invalid) {
     throws IllegalArgumentException();

Это тот случай, когда правило следует игнорировать. Обычно в точке входа в метод есть несколько защитных предложений, которые возвращают или выдают исключение ArgumentException, если переданные аргументы имеют неправильный формат. Просто держите эти утверждения кластеризованными в начале ваших методов.

Вы действительно должны взвесить затраты и выгоды, связанные с этим. Перевесят ли преимущества наличия только одного выражения return недостаток необходимости искажать метод, который должен быть довольно простым для написания?

Я бы пошел с нет для этого дела.

За исключением случаев, когда нет единой записи - единый выход В любом случае, правила больше не нужны, поэтому абсолютно не нужно следовать строгому «одному возврату». править. Поток управления может - теоретически - выйти из функции в любое время, вызвав исключение и размотав стек, так что даже если вы реализуете строгую «одну запись - один выход» В политике нет гарантии, что она будет соблюдаться вообще.

Не стесняйтесь выходить из функции в любое время, если она вам подходит!

Ваши методы в общих чертах не должны превышать «одного экрана». Если они это сделают, вы должны (в общем снова) попытаться разделить их на несколько методов. Это, вероятно, гораздо важнее, чем иметь «только одну инструкцию возврата» ...

В конце концов, мы ищем удобочитаемость.

Я твердо верю в «одну запись / один выход», за исключением проверки входных данных в верхней части функции. Это должно произойти до того, как начнется настоящая работа функции.

Я думаю, что это правило было направлено на то, чтобы не дать людям выйти из середины кода, который выполняет настоящую работу, просто потому, что они думают, что они "сделали".

Проблема с множественными возвратами заключается в том, что вы не можете быть уверены, что будет выполнена необходимая обработка выхода, например, закрытие сокета или освобождение какого-либо другого ресурса. 


public static string ChopText(string Text)
{
   string returnString = "";
   if(String.IsNullOrEmpty(Text))
   {
      returnString = "return string text";
   }
   return returnString;
}

Правило устарело. Легко и просто. Он существует, чтобы помочь плохим программистам писать более читаемый код ... Сделайте ваш код маленьким и читабельным, и избавьтесь от этого глупого правила.

Я категорически не согласен с идеей, что "одна запись на один выход" приводит к сложному коду. Я только что написал приложение для телефонов Blackberry и Android на Java, которое состоит примерно из 100 файлов, и нет ни одного метода, который не завершится в конце. Несмотря на то, что это приложение с графическим интерфейсом и многопоточное, ни один код не сложен. Мало, если какие-либо процедуры не видны полностью на экране. Я уже 46 лет занимаюсь разработкой и написанием программного обеспечения на всех языках, кроме нескольких языков и операционных систем, и для меня "одна запись один выход" делает для очень простой, легкий для чтения и обслуживания кода. Мои $ 0,02 стоит. Извините, если я растрепал перья.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top