Если еще одна лестница, которая должна охватывать все условия, следует ли добавить избыточный последний пункт?

Это то, чем я занимаюсь в последнее время.

Пример:

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else if (i > current) {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

Часто лестница if / else значительно сложнее, чем эта ...

Смотрите последний пункт? Это избыточно. Лестница должна в конечном итоге поймать все возможные условия. Таким образом, это можно переписать так:

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

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

Однако:

• Ясное написание окончательного исчерпывающего условия - моя собственная идея, и у меня плохой опыт с моими собственными идеями - обычно люди кричат ​​на меня о том, как ужасно то, что я делаю, - и (иногда очень) позже я узнаю, что это действительно было неоптимальным;
• Один намек на то, что это может быть плохой идеей: неприменимо к Javascript, но в других языках компиляторы склонны выдавать предупреждения или даже ошибки об управлении, достигающем конца функции. Хинтинг, делающий что-то подобное, может быть не слишком популярным, или я делаю это неправильно.
  • Жалобы компилятора заставили меня иногда написать последнее условие в комментарии, но я думаю, что это ужасно, поскольку комментарии, в отличие от кода, не влияют на фактическую семантику программы:

    } else { // i > current
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }

Я что-то пропустил? Или это нормально делать то, что я описал, или это плохая идея?

Оба подхода действительны. Но давайте подробнее рассмотрим плюсы и минусы.

Для ifцепочки с такими тривиальными условиями, как здесь, это не имеет значения:

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

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

• Финал else: ты уверен, что одна ветка занята. Если случится, что вы забыли один случай, он пройдет через последнюю ветвь, поэтому во время отладки, если была выбрана последняя ветка и вы ожидали чего-то другого, вы быстро разберетесь.
• final else if: вам нужно вывести избыточное условие для кода, и это создает потенциальный источник ошибок с риском не охватить все случаи. Кроме того, если вы пропустили случай, ничего не будет выполнено, и может быть сложнее обнаружить, что чего-то не хватает (например, если некоторые переменные, которые вы ожидали установить, сохраняют значения из предыдущих итераций).

Таким образом, последнее избыточное условие является источником риска. Вот почему я бы предпочел пойти в финал else.

Редактировать: высокая надежность кодирования

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

Это защитное кодирование. Рекомендуется некоторыми спецификациями безопасности, такими как SEI CERT или MISRA . Некоторые инструменты статического анализа даже реализуют это как правило , которое систематически проверяется (это может объяснить предупреждения вашего компилятора).

Что-то, чего не хватает в ответах до сих пор, является вопросом того, какой тип отказа менее вреден.

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

Вы опускаете последнее условие: последний вариант выполняется, даже если это не правильно.

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

Вы добавляете окончательное условное и исключение: оно бросает.

Вы должны решить, какой из этих вариантов является лучшим. В разработке кода я считаю, что это не просто - возьмите третий случай. Тем не менее, я бы, вероятно, установил circle.src на изображение ошибки, а circle.alt на сообщение об ошибке, прежде чем выбросить - в случае, если кто-то решит отключить утверждения позже, это сделает его безвредным.

Еще одна вещь, чтобы рассмотреть - каковы ваши варианты восстановления? Иногда у вас нет пути восстановления. То, что я считаю лучшим примером этого, - это первый запуск ракеты Ariane V. Произошла ошибка uncaught / 0 (на самом деле переполнение деления), которая привела к разрушению усилителя. На самом деле код, который вышел из строя, не имел никакого смысла в тот момент, он стал спорным в тот момент, когда зажглись бустеры. Как только они освещают его орбиту или бум, вы делаете все возможное, ошибки не могут быть допущены. (Если из-за этого ракета сбивается с пути, парень безопасности на дальности поворачивает ключ.)

То, что я рекомендую, это использовать assertутверждение в вашем последнем другом, в любом из этих двух стилей:

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else {
        assert i > current
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

Или утверждение мертвого кода:

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else if (i > current) {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    } else {
        assert False, "Unreachable code"
    }
}

Инструмент покрытия кода часто можно настроить так, чтобы он игнорировал код, например «assert False», из отчета о покрытии.

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

Я определил макрос «заявлено», который оценивает условие, и в отладочной сборке попадает в отладчик.

Поэтому, если я на 100 процентов уверен, что одно из трех условий должно быть выполнено, я пишу

If condition 1 ...
Else if condition 2 .,,
Else if asserted (condition3) ...

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

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

Это приводит к коду, который очень ясен:

setCircle(circle, i, { current })
{
    if (i == current)
    {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
        return
    }
    if (i < current)
    {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
        return
    }
    if (i > current)
    {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
        return
    }
    throw new Exception("Condition not handled.");
}

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