Должны ли операторы switch всегда содержать предложение по умолчанию?

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

1. Есть ли разумная причина всегда включать оператор по умолчанию?

2. Этот язык зависит? Я не помню, какой язык я использовал в то время - может быть, это относится к некоторым языкам, а не к другим?

Переключатель дел должен почти всегда иметь defaultдело.

Причины использовать default

1. «поймать» неожиданное значение

switch(type)
{
    case 1:
        //something
    case 2:
        //something else
    default:
        // unknown type! based on the language,
        // there should probably be some error-handling
        // here, maybe an exception
}

2. Для обработки действий «по умолчанию», где случаи для особого поведения.

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

3. Чтобы показать, что кто-то читает ваш код, вы рассмотрели этот случай.

variable = (variable == "value") ? 1 : 2;
switch(variable)
{
    case 1:
        // something
    case 2:
        // something else
    default:
        // will NOT execute because of the line preceding the switch.
}

Это был упрощенный пример, но суть в том, что тот, кто читает код, не должен удивляться, почему variableне может быть что-то, кроме 1 или 2.

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

switch(keystroke)
{
    case 'w':
        // move up
    case 'a':
        // move left
    case 's':
        // move down
    case 'd':
        // move right
    // no default really required here
}

Нет.

Что если нет действия по умолчанию, контекст имеет значение. Что делать, если вы хотите действовать только на нескольких ценностях?

Возьмите пример чтения нажатий клавиш для игры

switch(a)
{
   case 'w':
     // Move Up
     break;
   case 's':
     // Move Down
     break;
   case 'a':
     // Move Left
     break;
   case 'd':
     // Move Right
     break;
}

Добавление:

default: // Do nothing

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

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

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

enum SomeEnum
{
    ENUM_1,
    ENUM_2,
    // More ENUM values may be added in future
};

int foo(SomeEnum value)
{
    switch (value)
    {
    case ENUM_1:
        return 1;
    case ENUM_2:
        return 2;
    }
    // handle invalid values here
    return 0;
 }

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

Вещи могут и действительно пойти не так, как надо. Ценности будут не такими, как вы ожидаете, и так далее.

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

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

switch (myVar) {
   case 1: ......; break;
   case 2: ......; break;
   default: throw new RuntimeException("unreachable");
}

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

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

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

Должен ли оператор switch всегда включать предложение по умолчанию? Нет. Обычно включать в себя по умолчанию.

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

Вот тривиальный пример того, где это не имеет смысла:

void PrintSign(int i)
{
    switch (Math.Sign(i))
    {
    case 1:
        Console.Write("positive ");
        break;
    case -1:
        Console.Write("negative ");
        break;
    default: // useless
    }
    Console.Write("integer");
}

Это эквивалент:

void PrintSign(int i)
{
    int sgn = Math.Sign(i);
    if (sgn == 1)
        Console.Write("positive ");
    else if (sgn == -1)
        Console.Write("negative ");
    else // also useless
    {
    }
    Console.Write("integer");
}

Насколько я вижу, ответ «по умолчанию» является необязательным, говорить, что переключатель должен всегда содержать значение по умолчанию, все равно, что говорить, что каждое if-elseif должно содержать «else». Если есть логика, которая должна быть сделана по умолчанию, тогда должен присутствовать оператор 'default', но в противном случае код мог бы продолжать выполняться, ничего не делая.

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

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

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

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

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

switch(ResponseValue)
{
    default:
    case No:
        return false;
    case Yes;
        return true;
}

По крайней мере, это не обязательно в Java. Согласно JLS, он говорит, что может присутствовать как минимум один случай по умолчанию. Это означает, что ни один случай по умолчанию не приемлем. Время от времени также зависит от контекста, который вы используете оператор switch. Например, в Java следующий блок переключателей не требует регистра по умолчанию

private static void switch1(String name) {
    switch (name) {
    case "Monday":
        System.out.println("Monday");
        break;
    case "Tuesday":
        System.out.println("Tuesday");
        break;
    }
}

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

    private static String switch2(String name) {
    switch (name) {
    case "Monday":
        System.out.println("Monday");
        return name;

    case "Tuesday":
        System.out.println("Tuesday");
        return name;

    default:
        return name;
    }
}

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

Так говорят некоторые (устаревшие) руководства, такие как MISRA C :

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

Этот совет устарел, потому что он не основан на соответствующих в настоящее время критериях. Явное упущение - то, что сказал Харлан Кэслер:

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

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

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

Это также тот случай, когда Мисра придерживается позиции крайне оборонительного программирования, поэтому, пока недопустимое значение является физически представимым, его нужно проверять, независимо от того, является ли программа корректной. Что имеет смысл, если программное обеспечение должно быть максимально надежным при наличии аппаратных ошибок. Но, как сказал Офир Йоктан, большинство программного обеспечения лучше не «обрабатывать» ошибки. Последняя практика иногда называется оскорбительным программированием .

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

Однако я не согласен с Адрианом Смитом, что ваше сообщение об ошибке по умолчанию должно быть совершенно бессмысленным. Может быть необработанный случай, который вы не предвидели (что-то вроде этого), что ваш пользователь в конечном итоге увидит, и сообщение типа «недоступный» совершенно бессмысленно и никому не поможет в этой ситуации.

Например, сколько раз у вас был совершенно бессмысленный BSOD? Или фатальное исключение @ 0x352FBB3C32342?

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

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

Если возможности регистра ограничены (т. Е. Булево), то предложение по умолчанию является избыточным !

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

switch ( x ){
  case 0 : { - - - -}
  case 1 : { - - - -}
}

/* What happens if case 2 arises and there is a pointer
* initialization to be made in the cases . In such a case ,
* we can end up with a NULL dereference */

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

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

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

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

Я не согласен с наиболее проголосовавшим ответом Ванварила выше.

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

1. Неисчерпывающие операторы switch: они всегда должны иметь значение по умолчанию. Как следует из названия, это утверждения, которые не охватывают все возможные значения. Это также может быть невозможно, например, оператор switch для целочисленного значения или для String. Здесь я хотел бы использовать пример Vanwaril (Следует отметить, что я думаю, что он использовал этот пример, чтобы сделать неправильное предложение. Я использую его здесь, чтобы заявить обратное -> Использовать выражение по умолчанию):

   switch(keystroke)
   {
     case 'w':
       // move up
     case 'a':
       // move left
     case 's':
       // move down
     case 'd':
       // move right
     default:          
       // cover all other values of the non-exhaustive switch statement
   }
   

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

2. Исчерпывающие операторы переключения: Эти операторы переключения охватывают все возможные значения, например, оператор переключения для перечисления типов систем оценок. При разработке кода в первый раз легко охватить все значения. Однако, поскольку мы люди, есть небольшой шанс забыть о некоторых. Кроме того, если вы добавите значение enum позже, так что все операторы switch должны быть адаптированы, чтобы сделать их исчерпывающими, снова откроется путь в ад ошибки. Простое решение - инструмент статического анализа кода. Инструмент должен проверить все операторы switch и проверить, являются ли они исчерпывающими или имеют ли они значение по умолчанию. Вот пример для исчерпывающего оператора switch. Сначала нам нужно перечисление:

   public enum GradeSystemType {System1To6, SystemAToD, System0To100}
   

   Тогда нам нужна переменная этого перечисления, как GradeSystemType type = .... Исчерпывающий оператор switch будет выглядеть следующим образом:

   switch(type)
   {
     case GradeSystemType.System1To6:
       // do something
     case GradeSystemType.SystemAToD:
       // do something
     case GradeSystemType.System0To100:
       // do something
   }
   

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

Еще одна вещь. Если мы всегда используем defaultпредложение, может случиться так, что инструмент статического анализа кода не способен обнаруживать исчерпывающие или не исчерпывающие операторы переключения, поскольку он всегда обнаруживает defaultпредложение. Это очень плохо, так как мы не будем проинформированы, если мы расширим enum другим значением и забудем добавить его в один оператор switch.

Должны ли операторы switch всегда содержать предложение по умолчанию? Случаи переключений не могут существовать без случая по умолчанию, в случае переключателя значение switch(x)по умолчанию вызовет значение переключателя в этом случае x, если оно не совпадает с любыми другими значениями случая.

Я полагаю, что это довольно специфично для языка и для случая C ++ второстепенный момент для класса enum типа . Который кажется более безопасным, чем традиционное перечисление. НО

Если вы посмотрите на реализацию std :: byte, это выглядит примерно так:

enum class byte : unsigned char {} ;

Источник: https://en.cppreference.com/w/cpp/language/enum

А также учтите это:

В противном случае, если T является типом перечисления, который либо ограничен областью действия, либо имеет область действия с фиксированным базовым типом, и если в braced-init-list есть только один инициализатор, и если преобразование из инициализатора в базовый тип не сужается, и если инициализация - это прямая инициализация списка, затем перечисление инициализируется с результатом преобразования инициализатора в его базовый тип.

(начиная с C ++ 17)

Источник: https://en.cppreference.com/w/cpp/language/list_initialization

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

Однако мне действительно нравится то, что @Harlan Kassler сказал в своем посте, и я сам начну использовать эту стратегию в некоторых ситуациях.

Просто пример небезопасного класса enum:

enum class Numbers : unsigned
{
    One = 1u,
    Two = 2u
};

int main()
{
    Numbers zero{ 0u };
    return 0;
}