Чи інші блоки збільшують складність коду? [зачинено]

Ось дуже спрощений приклад . Це не обов'язково питання, що стосуються мови, і я прошу вас проігнорувати безліч інших способів написання функції та змін, які можуть бути внесені до неї. . Колір унікального типу

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блоку застосувати обмеження, яке має бути логічно задоволеним для всіх наступних кодів, таких як нульова перевірка (або будь-яка інша охорона) .

На мою думку, явний ще блок є кращим. Коли я бачу це:

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

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

Коли я бачу це:

if (sky.Color != Blue) {
   ...
} 
return 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 / порожнє поводження не є єдиною причиною охорони умов. Не майже! Хоча цей простий приклад зосереджується на NULL / порожній обробці та не містить інших причин, наприклад, пошук глибоких структур, таких як 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блок заявляє про наміри. Але мій висновок інший, тому що ви додаєте складності у своєму коді для досягнення цього.

Я не погоджуюся з вашим твердженням, що це дозволяє вам запобігти тонкі помилки в логіці.

Давайте подивимось приклад, тепер воно повинно повернутись істиною лише в тому випадку, якщо Небо синє і висока вологість, вологість невисока або якщо небо червоне. Але тоді ви помиляєтеся однією дужкою і розміщуєте її неправильно 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;
  

  }

• Якщо випадок складний, і не всі пропозиції повертають справжнє (можливо, вони повертають подвійний), і я хочу ввести якусь команду точки перерви або входу, я б розглядав щось на кшталт:

  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застереження.

Тому простота прикладу також є фактором, який слід враховувати.

Хоча описаний випадок «інше» має більшу складність, у більшості (але не у всіх) практичних ситуаціях це не має великого значення.

Роки тому, коли я працював над програмним забезпеченням, яке використовувалося в авіаційній галузі (воно повинно було пройти процес сертифікації), ваше питання виникло. З'ясувалося, що на цю "іншу" заяву були фінансові витрати, оскільки вона збільшувала складність коду.

Ось чому.

Наявність «іншого» створило неявний 3-й випадок, який потрібно було оцінити, - ні про «якщо», ні про «інше». Ви можете думати (як я був у той час) 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робить лише одне. )

Повертаючись до коду ОП, я думаю, що це може послужити керівництвом щодо складності elseвисловлювань: Код з явним elseтвердженням об'єктивно складніше, але важливіше, чи робить це семантику коду зрозумілою та простою. І на це потрібно відповідати в кожному конкретному випадку, оскільки кожен фрагмент коду має різний зміст.

Я думаю, це залежить від того, який вигляд ifви використовуєте. Деякі ifтвердження можна розглядати як вирази, а інші можна розглядати лише як оператори контрольного потоку.

Ваш приклад для мене виглядає як вираз. У мовах, подібних С, потрійний оператор ?:дуже схожий на ifтвердження, але це вираз, а іншу частину не можна опустити. Має сенс, що інша гілка не може бути опущена в виразі, оскільки вираз завжди повинен мати значення.

Використовуючи потрійний оператор, ваш приклад виглядатиме так:

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

Оскільки це булевий вираз, його справді слід спростити до кінця

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

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

Ще одна річ, яку слід задуматися в цьому аргументі, - це звички, які просуває кожен підхід.

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

• В інших випадках існує лише один шлях виконання, і тоді всі ті виняткові речі, про які повинні хвилюватися програмісти. Як ви вже згадували, охоронні застереження чудово підходять для цього.

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

Основний принцип, про який я маю на увазі, полягає в тому, що метод або функція повинні мати лише одне призначення. Будь-який код із оператором if / else або switch призначений лише для розгалуження. Тож він повинен бути абсурдно коротким (4 рядки) і лише делегувати правильний метод або дати очевидний результат (наприклад, ваш приклад). Якщо ваш код такий короткий, важко пропустити ці багаторазові повернення :) Начебто "goto вважається шкідливим", будь-яке розгалуження може бути зловживано, тому вводити критичну думку в інші твердження, як правило, варто. Як ви вже згадували, просто наявність ще одного блоку забезпечує місце для збиття коду. Ви та ваша команда повинні будете вирішити, як ви ставитесь до цього.

На що інструмент насправді скаржиться - це той факт, що у вас є повернення / перерва / кидок всередині блоку if. Що стосується цього, ви написали охоронний застереження, але накрутили його. Ви можете обрати інструмент щасливим або можете "розважити" його пропозицію, не приймаючи.

Я думаю, відповідь - це залежить. Ваш зразок коду (як ви побічно вказуєте) просто повертає оцінку стану і найкраще представлений, як ви, очевидно, знаєте, як один вираз.

Для того, щоб визначити, чи додає ще одна умова, уточнює чи затемнює код, потрібно визначити, що собою являє IF / ELSE. Це вираз (як у вашому прикладі)? Якщо так, цей вираз слід витягнути і використовувати. Це стан охорони? Якщо так, то ELSE є непотрібним та оманливим, оскільки це робить дві гілки рівнозначними. Це приклад процесуального поліморфізму? Витягніть його. Це встановлення передумов? Тоді це може бути суттєво.

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

Відповідь трохи суб’єктивна. elseБлок може допомогти читаність, встановивши , що один блок коду виконується виключно до іншого блоку коду, без необхідності , щоб прочитати обох блоків. Це може бути корисно, якщо, скажімо, обидва блоки відносно довгі. Є випадки, хоча де ifбез 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(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це не було б окремою функцією, тому різниця була б ще більшою.)

Так, складність збільшується, оскільки інша стаття зайва . Таким чином, краще, щоб не залишати код слабким і середнім. Це на тому ж акорді, як пропущення надлишкових 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 повертає логічне значення . Якщо нічого особливого не відбувається, воно повертається помилковим «Це перше читання, зверху вниз.

І тоді ви «розбираєте» умову »Якщо умова виконана, вона повертається істиною « Ви могли повністю пропустити умовне і зрозуміли, що ця функція виконує у випадку за замовчуванням . Вашому оку та розуму залишається лише проглядати деякі букви з лівого боку, не читаючи частини праворуч.

Я маю враження, що інше, безпосередньо прямо заявляє про наміри, заявляючи про те, що код в обох блоках безпосередньо пов'язаний.

Так це правильно. Але ця інформація є зайвою . У вас є випадок за замовчуванням і один "виняток", який охоплюєтьсяif викладом.

Маючи справу зі складнішими структурами, я б обрав іншу стратегію, опускаючи ifабо зовсім некрасивого брата switch.

Якщо коротко розповісти, у цьому випадку добре позбутися elseключового слова. Тут абсолютно непотрібно, і залежно від того, як ви форматуєте свій код, він додасть до вашого коду ще одну-три абсолютно непотрібні рядки. Поміркуйте, що в ifблоці:

return true;

Отже, якщо ifблок повинен був бути введений, весь решта функції, за визначенням, не виконується. Але якщо він не введений, оскільки немає поданих ifтверджень, вся решта функції виконується. Було б зовсім інше, якби returnзаява не була в ifблоці, і в цьому випадку наявність або відсутністьelse блоку матиме вплив, але тут це не мало би впливу.

У своєму запитанні, перевернувши свій ifстан і пропустивши else, ви вказали наступне:

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

Тоді їм потрібно трохи ближче прочитати код. Ми використовуємо мови високого рівня та чітку організацію коду для пом'якшення цих проблем, але додавання абсолютно зайвого elseблоку додає коду "шум" та "захаращення", і нам не слід також інвертувати чи повторно інвертувати наші ifумови. Якщо вони не можуть сказати різницю, то вони не знають, що роблять. Якщо вони можуть сказати різницю, то вони завжди можуть самі перевернути початкові ifумови.

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

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

Чи збільшується рівень складності, не включаючи ще блок?

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

У конкретному прикладі, який ви навели, це і є.

• Він змушує рецензента ще раз прочитати код, щоб переконатися, що це не помилка.
• Він додає (зайву) цикломатичну складність, оскільки додає один вузол до графіка потоку.

Я думаю, що це не могло стати простішим, що це:

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;
    }
}

Зауважте, що використання потрійних операторів для розгалуження між виразами є загальним у функціональному програмуванні.