Другие блоки увеличивают сложность кода? [закрыто]

Вот очень упрощенный пример . Это не обязательно вопрос конкретного языка, и я прошу вас игнорировать многие другие способы написания функции и внесения в нее изменений. , Цвет уникального типа

string CanLeaveWithoutUmbrella()
{
    if(sky.Color.Equals(Color.Blue))
    {
        return "Yes you can";
    }
    else
    {
        return "No you can't";
    }
}

Многие люди, с которыми я встречался, ReSharper, и этот парень (чей комментарий напомнил мне, что я некоторое время просил об этом) рекомендуют рефакторинг кода, чтобы удалить elseблок, оставив этот:

(Я не могу вспомнить, что сказал большинство, иначе я бы не спросил)

string CanLeaveWithoutUmbrella()
{
    if(sky.Color.Equals(Color.Blue))
    {
        return "Yes you can";
    }
    return "No you can't";
}

Вопрос: Есть ли увеличение сложности, вызванное отсутствием elseблока?

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

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

Возьмите этот вариант моего упрощенного примера (игнорируя тот факт, что orоператор, поскольку это намеренно упрощенный пример):

bool CanLeaveWithoutUmbrella()
{
    if(sky.Color != Color.Blue)
    {
        return false;
    }
    return true;
}

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

Если бы elseблок присутствовал, то кто бы ни добавил новое условие, он будет вынужден переместить содержимое elseблока (и если каким-то образом они затенят его, эвристика покажет, что код недоступен, чего не происходит в случае, когда одно ifограничивает другое) ,

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

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

Я забыл упомянуть случай, в котором я согласен с пропуском блока else, и это при использовании ifблока для применения ограничения, которое должно быть логически выполнено для всего следующего кода, такого как нулевая проверка (или любые другие средства защиты) ,

На мой взгляд, явный блок else предпочтительнее. Когда я вижу это:

if (sky.Color != Blue) {
   ...
}  else {
   ...
}

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

Когда я вижу это:

if (sky.Color != Blue) {
   ...
} 
return false;

На первый взгляд кажется, что он возвращает false независимо, и имеет дополнительный побочный эффект, небо не голубое.

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

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

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

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

Вскоре после первоначальной версии этого ответа в моем проекте был обнаружен подобный код:

Foobar merge(Foobar left, Foobar right) {
   if(!left.isEmpty()) {
      if(!right.isEmpty()) {
          Foobar merged = // construct merged Foobar
          // missing return merged statement
      }
      return left;
   }
   return right;
}

Не помещая возврат внутрь elses, тот факт, что заявление о возвращении отсутствовало, упускалось из виду. Если бы еще был занят, код даже не скомпилирован. (Конечно, гораздо большее беспокойство у меня вызывает то, что тесты, написанные на этом коде, были довольно плохими, чтобы не обнаружить эту проблему.)

Основная причина удаления elseблока, который я обнаружил, заключается в избыточном отступе. Короткое замыкание elseблоков обеспечивает гораздо более плавную структуру кода.

Многие ifзаявления по сути являются охранниками. Они предотвращают разыменование нулевых указателей и других «не делайте этого!» ошибки. И они приводят к быстрому прекращению текущей функции. Например:

if (obj === NULL) {
    return NULL;
}
// further processing that now can assume obj attributes are set

Теперь может показаться, что здесь elseбыло бы очень разумно:

if (obj === NULL) {
    return NULL;
}
else if (obj.color != Blue) {
   // handle case that object is not blue
}

И действительно, если это все, что вы делаете, это не намного больше отступ, чем в примере выше. Но это редко все, что вы делаете с реальными многоуровневыми структурами данных (условие, которое возникает постоянно при обработке распространенных форматов, таких как JSON, HTML и XML). Поэтому, если вы хотите изменить текст всех дочерних элементов данного узла HTML, скажите:

elements = tree.xpath(".//p");
if (elements === NULL) {
    return NULL;
}
p = elements[0]
if ((p.children === NULL) or (p.children.length == 0)) {
    return NULL;
}
for (c in p.children) {
    c.text = c.text.toUpperCase();
}
return p;

Охранники не увеличивают отступ кода. С elseпредложением вся фактическая работа начинает перемещаться вправо:

elements = tree.xpath(".//p");
if (elements === NULL) {
    return NULL;
}
else {
    p = elements[0]
    if ((p.children === NULL) or (p.children.length == 0)) {
        return NULL;
    }
    else {
        for (c in p.children) {
            c.text = c.text.toUpperCase();
        }
        return p;
    }
}

Это начинает иметь значительное движение вправо, и это довольно тривиальный пример, только с двумя условиями охраны. Каждый дополнительный охранник добавляет еще один уровень отступа. Реальный код, который я написал, обрабатывая XML или потребляя подробные потоки JSON, может легко составлять 3, 4 или более сторожевых условий. Если вы всегда используете else, вы в конечном итоге с отступом 4, 5 или 6 уровней. Может быть, больше. И это определенно способствует ощущению сложности кода и увеличению времени, затрачиваемого на понимание того, что соответствует чему. Быстрый, плоский стиль раннего выхода устраняет некоторые из этих «лишних структур» и кажется более простым.

Приложение Комментарии к этому ответу заставили меня понять, что, возможно, не было ясно, что обработка NULL / empty не единственная причина для условных выражений защиты. Не почти! Хотя этот простой пример фокусируется на обработке пустых / пустых значений и не содержит других причин, поиск глубоких структур, таких как XML и AST, например, для «релевантного» контента часто содержит длинный ряд специальных тестов для отсеивания нерелевантных узлов и неинтересных случаев. Серия тестов «если этот узел не релевантен, возврат» вызовет тот же тип правостороннего дрейфа, что и NULL / пустые охранники. И на практике последующие тесты релевантности часто сочетаются с NULL / пустыми защитными элементами для соответственно более глубоких искомых структур данных - двойной удар для смещения вправо.

Когда я вижу это:

if(something){
    return lamp;
}
return table;

Я вижу общую идиому . Распространенный паттерн , который в моей голове звучит так:

if(something){
    return lamp;
}
else return table;

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

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

Например, прочитайте следующий текст:

Вы читали это?

Я люблю Париж весной

Если это так, вы не правы. Прочитай текст еще раз. Что на самом деле написано

Я люблю Париж в в весеннее время

В тексте есть два слова "the". Так почему ты пропустил один из двух?

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

То же самое с вышеупомянутой идиомой. Программисты , которые читали много кода привыкли видеть эту картину , из if(something) {return x;} return y;. Им не нужен опыт, elseчтобы понять его смысл, потому что их мозг «помещает это для них». Они распознают его как шаблон с известным значением: «то, что после закрывающей скобки будет работать только как неявное elseиз предыдущего if».

Так что, на мой взгляд, это elseне нужно. Но просто используйте то, что кажется более читабельным.

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

Однако верно и обратное: чрезмерный рефакторинг для уменьшения длины кода также может добавить сложность (конечно, не в этом простом случае).

Я согласен с утверждением, что elseблок заявляет о намерениях. Но мой вывод другой, потому что вы добавляете сложность в свой код для достижения этой цели.

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

Давайте посмотрим на пример, теперь он должен возвращать true только в том случае, если небо синее, а влажность высокая, влажность не высокая или небо красное. Но тогда вы ошибаетесь в одной скобке и помещаете ее в неправильную else:

bool CanLeaveWithoutUmbrella() {
    if(sky.Color == Color.Blue)
    {
        if (sky.Humidity == Humidity.High) 
        {
            return true;
        } 
    else if (sky.Humidity != Humidity.High)
    {
        return true;
    } else if (sky.Color == Color.Red) 
    {
            return true;
    }
    } else 
    {
       return false;
    }
}

Мы видели все подобные глупые ошибки в рабочем коде, и их может быть очень трудно обнаружить.

Я бы предложил следующее:

Я считаю, что это легче читать, потому что я сразу вижу, что по умолчанию false.

Кроме того, идея принудительного перемещения содержимого блока для вставки нового предложения подвержена ошибкам. Это как-то связано с принципом открытия / закрытия (код должен быть открыт для расширения, но закрыт для модификации). Вы вынуждены изменить существующий код (например, кодер может ввести ошибку в балансировку фигурных скобок).

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

• Если случай такой же простой, как и представленный, мой ответ будет состоять в том, чтобы вообще пропустить любые if elseпункты.

  возврат (sky.Color == Color.Blue);

• Если дело немного сложнее, с различными предложениями, я бы ответил:

  bool CanLeaveWithoutUmbrella () {

  if(sky.Color == Color.Blue && sky.Humidity == Humidity.High) {
      return true;
  } else if (sky.Humidity != Humidity.High) {
      return true;
  } else if (sky.Color == Color.Red) {
      return true;
  }
  
  return false;
  

  }

• Если дело сложное и не все предложения возвращают true (может быть, они возвращают double), и я хочу ввести некоторую точку останова или команду loggin, я бы рассмотрел что-то вроде:

  double CanLeaveWithoutUmbrella() {
  
      double risk = 0.0;
  
      if(sky.Color == Color.Blue && sky.Humidity == Humidity.High) {
          risk = 1.0;
      } else if (sky.Humidity != Humidity.High) {
          risk = 0.5;
      } else if (sky.Color == Color.Red) {
          risk = 0.8;
      }
  
      Log("value of risk:" + risk);
      return risk;
  

  }

• Если мы говорим не о методе, который возвращает что-то, а о блоке if-else, который устанавливает некоторую переменную или вызывает метод, тогда да, я бы включил последний elseпункт.

Поэтому простота примера также является фактором, который необходимо учитывать.

Хотя описанный случай if-else имеет большую сложность, в большинстве (но не во всех) практических ситуациях он не имеет большого значения.

Несколько лет назад, когда я работал над программным обеспечением, которое использовалось для авиационной промышленности (оно должно было пройти процесс сертификации), у вас возник вопрос. Оказалось, что это утверждение «else» связано с финансовыми затратами, поскольку оно увеличивает сложность кода.

Вот почему

Присутствие «else» создало неявный 3-й случай, который должен был быть оценен - ​​ни «if», ни «else» не были взяты. Вы можете думать (как я был в то время) WTF?

Объяснение пошло так ...

С логической точки зрения, есть только два варианта - «если» и «еще». Тем не менее, мы сертифицировали объектный файл, который генерировал компилятор. Поэтому, когда было «другое», необходимо было провести анализ, чтобы подтвердить, что сгенерированный код ветвления был правильным и что загадочный 3-й путь не появился.

Сравните это со случаем, когда есть только «если» и нет «еще». В этом случае есть только два варианта - путь «если» и путь «не если». Два случая для оценки менее сложны, чем три.

Надеюсь это поможет.

Самая важная цель кода - быть понятным как зафиксированный (в отличие от простого рефакторинга, который полезен, но менее важен). Несколько более сложный пример Python может быть использован для иллюстрации этого:

def value(key):
    if key == FROB:
        return FOO
    elif key == NIK:
        return BAR
    [...]
    else:
        return BAZ

Это довольно ясно - это эквивалент caseпоиска оператора или словаря, версия более высокого уровня return foo == bar:

KEY_VALUES = {FROB: FOO, NIK: BAR, [...]}
DEFAULT_VALUE = BAZ

def value(key):
    return KEY_VALUES.get(key, default=DEFAULT_VALUE)

Это более понятно, потому что, хотя количество токенов больше (32 против 24 для исходного кода с двумя парами ключ / значение), семантика функции теперь явная: это просто поиск.

(Это имеет последствия для рефакторинга - если вы хотите получить побочный эффект, если у key == NIKвас есть три варианта:

1. Вернитесь к стилю if/ elif/ elseи вставьте одну строчку в key == NIKкейс.
2. Сохраните результат поиска в значение и добавьте ifоператор valueдля особого случая перед возвратом.
3. Поместите ifзаявление в звонящего.

Теперь мы понимаем, почему функция поиска является мощным упрощением: третий вариант, очевидно, является самым простым решением, поскольку помимо того, что он даетvalue меньшую разницу, чем первый, он единственный, который обеспечивает выполнение только одного действия. )

Возвращаясь к коду OP, я думаю, что это может служить руководством для сложности elseоператоров: код с явным elseоператором объективно более сложен, но более важно то, делает ли он семантику кода ясной и простой. И на это нужно отвечать в каждом конкретном случае, поскольку каждый фрагмент кода имеет свое значение.

Я думаю, это зависит от того, какое ifзаявление вы используете. Некоторые ifоператоры можно рассматривать как выражения, а другие - только как операторы потока управления.

Ваш пример выглядит как выражение для меня. В языках, подобных C, троичный оператор ?:очень похож на ifоператор, но это выражение, и часть else не может быть пропущена. Имеет смысл, что ветвь else не может быть опущена в выражении, потому что выражение всегда должно иметь значение.

Используя троичный оператор, ваш пример будет выглядеть так:

bool CanLeaveWithoutUmbrella()
{
    return (sky.Color == Color.Blue)
               ? true
               : false;
}

Так как это логическое выражение, оно действительно должно быть упрощено вплоть до

bool CanLeaveWithoutUmbrella()
{
    return (sky.Color == Color.Blue);
}

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

Еще одна вещь, о которой следует подумать в этом аргументе, - это привычки, которые продвигает каждый подход.

• if / else переопределяет образец кода в терминах ветвей. Как вы говорите, иногда это явно хорошо. На самом деле есть два возможных пути выполнения, и мы хотим это подчеркнуть.

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

• Конечно, есть случай 3 или более (n), где мы обычно рекомендуем отказаться от цепочки if / else и использовать оператор case / switch или полиморфизм.

Руководящий принцип, который я имею в виду, заключается в том, что метод или функция должны иметь только одну цель. Любой код с оператором if / else или switch предназначен только для ветвления. Поэтому он должен быть абсурдно коротким (4 строки) и делегироваться только на правильный метод или давать очевидный результат (как в вашем примере). Когда ваш код такой короткий, трудно пропустить эти множественные возвраты :) Во многом как «goto считать вредным», любое утверждение ветвления может быть использовано неправильно, поэтому обычно стоит добавить некоторые критические соображения в операторы else. Как вы упомянули, просто наличие блока else обеспечивает место для скопления кода. Вы и ваша команда должны решить, как вы к этому относитесь.

На что инструмент действительно жалуется, так это тот факт, что у вас есть возврат / разрыв / бросок внутри блока if. Итак, что касается этого, вы написали пункт охраны, но облажались. Вы можете сделать инструмент счастливым или «развлечь» его предложение, не принимая его.

Я думаю, что ответ зависит от этого. Ваш пример кода (как вы косвенно указываете) просто возвращает оценку условия и лучше всего представляется, как вы, очевидно, знаете, в виде одного выражения.

Чтобы определить, будет ли добавление условия else пояснять или затенять код, вам необходимо определить, что представляет IF / ELSE. Это (как в вашем примере) выражение? Если так, то это выражение должно быть извлечено и использовано. Это условие охраны? Если так, то ELSE является ненужным и вводящим в заблуждение, поскольку это делает две ветви кажущимися эквивалентными. Это пример процедурного полиморфизма? Извлеките это. Это предварительные условия? Тогда это может быть важно.

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

Ответ немного субъективен. elseБлок может помочь читаемость, установив , что один блок кода выполняется исключительно к другому блоку кода, без необходимости , чтобы прочитать обоих блоков. Это может быть полезно, если, скажем, оба блока относительно длинные. Есть случаи, когда наличие ifs без elses может быть более читабельным. Сравните следующий код с количеством if/elseблоков:

if(a == b) {
    if(c <= d) {
        if(e != f) {
            a.doSomeStuff();
            c.makeSomeThingsWith(b);
            f.undo(d, e);
            return 9;
        } else {
            e++;
            return 3;
        }
    } else {
        return 1;
    }
} else {
    return 0;
}

с:

if(a != b) {
    return 0;
}

if(c > d) {
    return 1;
}

if(e != f) {
    e++;
    return 3;
}

a.doSomeStuff();
c.makeSomeThingsWith(b);
f.undo(d, e);
return 9;

Второй блок кода превращает вложенные ifоператоры в охранные предложения. Это уменьшает отступы и делает некоторые условия возврата более понятными («если a != b, тогда мы вернемся 0!»)

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

Мы могли бы написать первый блок кода вот так, чтобы сделать его более читабельным:

if(a != b) {
    return 0;
} else if(c > d) {
    return 1;
} else if(e != f) {
    e++;
    return 3;
} else {
    a.doSomeStuff();
    c.makeSomeThingsWith(b);
    f.undo(d, e);
    return 9;
}

Этот код эквивалентен обоим вышеупомянутым блокам, но он представляет некоторые проблемы. Предложение elseздесь соединяет эти операторы if вместе. В приведенной выше версии статьи об охране пункты охраны не зависят друг от друга. Добавление нового означает просто написание нового ifмежду последней ifи остальной логикой. Здесь это тоже можно сделать, лишь с небольшим увеличением когнитивной нагрузки. Разница, однако, заключается в том, что перед новым предложением защиты должна появиться некоторая дополнительная логика. Когда заявления были независимыми, мы могли сделать:

...
if(e != f) {
    e++;
    return 3;
}

g.doSomeLogicWith(a);

if(!g.isGood()) {
    return 4;
}

a.doSomeStuff();
...

С подключенным if/else цепью это сделать не так просто. На самом деле, самый простой путь - это разорвать цепочку, чтобы она выглядела скорее как версия предложения гвардии.

Но на самом деле это имеет смысл. Использование if/elseслабо подразумевает связь между частями. Мы могли бы предположить , что a != bкакое - то образом связаны с c > dв if/elseцепи , версии. Это предположение будет вводить в заблуждение, как мы можем видеть из версии пункта охраны, что на самом деле они не связаны между собой. Это означает, что мы можем делать больше с независимыми предложениями, например, переупорядочивать их (возможно, для оптимизации производительности запросов или для улучшения логического потока). Мы также можем когнитивно игнорировать их, как только мы их пройдем. В if/elseцепочке я менее уверен, что отношения эквивалентности между aиb не всплывет позже.

Отношения, подразумеваемые посредством else, также очевидны в глубоко вложенном примере кода, но по-другому. Операторы elseотделены от условных, к которым они прикреплены, и они связаны в обратном порядке с условными (первое elseприсоединено к последнему if, последнее elseприсоединено к первому if). Это создает когнитивный диссонанс, когда мы вынуждены возвращаться назад по коду, пытаясь выровнять отступы в нашем мозгу. Это все равно что пытаться сопоставить кучу скобок. Будет еще хуже, если отступ будет неправильным. Дополнительные скобки тоже не помогают.

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

Это хорошая уступка, но она не лишает законной силы любой ответ. Я мог бы сказать, что в вашем примере кода:

bool CanLeaveWithoutUmbrella()
{
    if(sky.Color != Color.Blue)
    {
        return false;
    }
    return true;
}

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

Что делать, если я скажу, что если цвет неба черный, это ясная ночь, поэтому зонтик не нужен. (Есть более простые способы написать это, но есть более простые способы написать весь пример.)

bool CanLeaveWithoutUmbrella()
{
    if(sky.Color == Color.Blue)
    {
        return true;
    }

    if(sky.Color == Color.Black)
    {
        return true;
    }

    return false;
}

Как и в более крупном примере, приведенном выше, я могу просто добавить новое предложение без особой необходимости. Вif/else , я не могу быть уверен, что я ничего не испорчу, особенно если логика более сложная.

Я также укажу, что ваш простой пример тоже не так прост. Тест для недвоичного значения не совпадает с обратным тесту с инвертированными результатами.

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

void DoOneOfTwoThings(bool which)
{
    if (which)
        DoThingOne();
    else
        DoThingTwo();
}

... более читабельно, чем ...

void DoOneOfTwoThings(bool which)
{
    if (which) {
        DoThingOne();
        return;
    }
    DoThingTwo();
}

... потому что первый демонстрирует параллельную структуру, а второй нет. Но когда основная часть функции посвящена одной задаче, и вам просто нужно сначала проверить некоторые предварительные условия, ...

void ProcessInputOfTypeOne(String input)
{
    if (InputIsReallyTypeTwo(input)) {
        ProcessInputOfTypeTwo(input);
        return;
    }
    ProcessInputDefinitelyOfTypeOne(input);

}

... более читабельно, чем ...

void ProcessInputOfTypeOne(String input)
{
    if (InputIsReallyTypeTwo(input))
        ProcessInputOfTypeTwo(input);
    else
        ProcessInputDefinitelyOfTypeOne(input);
}

... потому что намеренно не устанавливая параллельную структуру дает подсказку будущему читателю, что получение ввода "действительно типа два" здесь ненормально . (В реальной жизни ProcessInputDefinitelyOfTypeOneне было бы отдельной функции, поэтому разница была бы еще более резкой.)

Да, сложность возрастает, поскольку предложение else является избыточным . Таким образом, лучше оставить этот код более скудным и подлым. Это соответствует тому же принципу, что и исключение избыточных thisквалификаторов (Java, C ++, C #), исключение скобок в returnоператорах и т. Д.

Хороший программист думает "что я могу добавить?" в то время как великий программист думает «что я могу удалить?».

Я заметил, передумал по этому делу.

Когда мне задали этот вопрос около года назад, я бы ответил примерно так:

»Должен быть только один entryи один exitметод« И с учетом этого я бы предложил изменить код на:

bool CanLeaveWithoutUmbrella()
{
    bool result

    if(sky.Color == Color.Blue)
    {
        result = true;
    }
    else
    {
        result = false;
    }

    return result;
}

С точки зрения коммуникации понятно , что нужно делать. Ifчто-то имеет место, манипулируйте результатом одним способом , else манипулируйте им другим способом .

Но это связано с ненужным else . elseВыражает по умолчанию случаю . Таким образом, на втором этапе я мог бы изменить его

bool CanLeaveWithoutUmbrella()
{
    bool result=false

    if(sky.Color == Color.Blue)
    {
        result = true;
    }
    return result;
}

Тогда возникает вопрос: зачем вообще использовать временную переменную? Следующий шаг рефакторизации приводит к:

bool CanLeaveWithoutUmbrella()
{

    if(sky.Color == Color.Blue)
    {
        return true;
    }
    return false;
}

Так что это ясно в том, что он делает. Я бы даже пошел еще дальше:

bool CanLeaveWithoutUmbrella()
{

    if(sky.Color == Color.Blue) return true;
    return false;
}

Или для слабонервных :

bool CanLeaveWithoutUmbrella()
{

    if(sky.Color == Color.Blue) { return true; }
    return false;
}

Вы можете прочитать это так: »CanLeaveWithoutUmbrella возвращает bool . Если ничего особенного не происходит, возвращается false «Это первое чтение сверху вниз.

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

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

Да, именно так. Но эта информация избыточна . У вас есть случай по умолчанию и одно «исключение», которое покрываетсяif -statement.

Имея дело со сложными структурами, я бы выбрал другую стратегию, исключив ifили switchвообще уродливого брата .

Короче говоря, в этом случае избавиться от elseключевого слова - это хорошая вещь. Здесь это полностью избыточно, и в зависимости от того, как вы форматируете свой код, оно добавит еще одну-три совершенно бесполезных строки в ваш код. Посмотрим, что в ifблоке:

return true;

Следовательно, если ifблок должен быть введен, вся остальная функция по определению не выполняется. Но если он не введен, поскольку дальнейших ifоператоров нет, вся остальная функция выполняется. Было бы совершенно иначе, если бы returnоператор не находился в ifблоке, в этом случае наличие или отсутствие elseблока оказало бы влияние, но здесь это не оказало бы влияния.

В своем вопросе, изменив свое ifусловие и пропустив else, вы заявили следующее:

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

Они должны читать код немного более внимательно. Мы используем языки высокого уровня и четкую организацию кода, чтобы смягчить эти проблемы, но добавление полностью избыточного elseблока добавляет «шум» и «беспорядок» в код, и нам также не нужно инвертировать или ревертировать наши ifусловия. Если они не могут понять разницу, то они не знают, что делают. Если они могут заметить разницу, то они всегда могут инвертировать исходные ifусловия сами.

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

Это, по сути, то, что здесь происходит, хотя. Вы возвращаетесь из ifблока, так что ifоценка условия false является ограничением, которое должно быть логически выполнено для всего следующего кода.

Есть ли увеличение сложности, вызванное отсутствием блока else?

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

В приведенном вами конкретном примере это так.

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

Я думаю, что это не может быть проще, чем это:

bool CanLeaveWithoutUmbrella()
{
    return (sky.Color == Color.Blue);
}

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

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool CanLeaveWithoutUmbrella()
    {
        if(this.color == Color.Blue)
        {
            return true;
        }
        else
        {
            return false;
        }
    }
}

Наше намерение, кажется, что мы можем уйти без зонта, когда небо голубое. Однако это простое намерение теряется в море кода. Есть несколько способов облегчить понимание.

Во-первых, у вас есть вопрос о elseфилиале. Я не против в любом случае, но, как правило, опускаю else. Я понимаю аргумент о явной явности, но мое мнение таково, что ifоператоры должны заключать в себе «необязательные» ветки, например, return trueодну. Я бы не назвал return falseветку «необязательной», так как она действует по умолчанию. В любом случае, я считаю это очень незначительной проблемой, и гораздо менее важной, чем следующие:

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool CanLeaveWithoutUmbrella()
    {
        if(this.color == Color.Blue)
        {
            return true;
        }
        return false;
    }
}

Гораздо более важный вопрос заключается в том , что ваши филиалы делают слишком много! Ветви, как и все, должны быть «максимально простыми, но не более». В этом случае вы использовали ifоператор, который разветвляется между блоками кода (коллекциями операторов), когда все, что вам действительно нужно для разветвления, это выражения (значения). Это понятно, так как а) ваши блоки кода содержат только отдельные операторы и б) они являются одним и тем же оператором ( return). Мы можем использовать троичный оператор, ?:чтобы сузить ветвь только до той части, которая отличается:

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool CanLeaveWithoutUmbrella()
    {
        return (this.color == Color.Blue)
            ? true
            : false;
    }
}

Теперь мы достигли очевидной избыточности, с которой наш результат идентичен this.color == Color.Blue. Я знаю, что ваш вопрос просит нас игнорировать это, но я думаю, что очень важно указать, что это процедурный образ мышления первого порядка: вы разбиваете входные значения и создаете некоторые выходные значения. Это хорошо, но, если возможно, гораздо эффективнее мыслить в терминах отношений или преобразований между входом и выходом. В этом случае отношения очевидно, что они одинаковы, но я часто вижу такой сложный процедурный код, который затемняет некоторые простые отношения. Давайте продолжим и сделаем это упрощение:

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool CanLeaveWithoutUmbrella()
    {
        return (this.color == Color.Blue);
    }
}

Следующая вещь , которую я бы указать на то , что ваш API содержит двойной негатив: это возможно , CanLeaveWithoutUmbrellaчтобы быть false. Это, конечно, упрощает NeedUmbrellaбыть true, поэтому давайте сделаем это:

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool NeedUmbrella()
    {
        return (this.color != Color.Blue);
    }
}

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

В объектно-ориентированном коде все блоки кода являются методами, и все ветвления выполняются с помощью динамической диспетчеризации , например. используя классы или прототипы. Можно спорить, упрощает ли это вещи, но это должно сделать ваш код более совместимым с остальной частью языка:

class Sky {
    bool NeedUmbrella()
    {
        return true;
    }
}

class BlueSky extends Sky {
    bool NeedUmbrella()
    {
        return false;
    }
}

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