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

Во время недавнего обзора кода меня попросили поместить defaultдела во все файлы, где бы ни использовался switchблок, даже если нечего делать default. Это означает, что я должен положить defaultдело и ничего не писать в нем.

Это правильная вещь? Какой цели это будет служить?

Кажется, есть три случая, когда defaultутверждение не нужно:

1. никаких других случаев не осталось, потому что есть ограниченный набор значений, которые вводят switch case. Но это может измениться со временем (преднамеренно или случайно), и было бы хорошо иметь, default caseесли что-то изменится - вы можете войти или предупредить пользователя о неправильном значении.

2. Вы знаете, как и где switch caseбудет использоваться и какие значения будут вводить его. Опять же, это может измениться, и может потребоваться дополнительная обработка.

3. другие случаи не требуют специальной обработки. Если это так, я думаю, что вас попросят добавить default case, потому что это принятый стиль кодирования, и он делает ваш код более читабельным.

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

Правильно ли это сделать? Какой цели это будет служить?

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

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

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

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

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

Синтаксически говоря, ответ - нет, нет. Но есть однако ...

Предложение defaultможет быть там по крайней мере по двум причинам:

1. Как обработчик ошибок - конечно, никогда не должен попасть сюда! это требование, которое может быть сделано, но что, если это так? Повреждение данных или, что еще хуже, отсутствие проверки данных являются путями сбоя программы, если они не были должным образом перехвачены. В этом случае это не должно быть пустым предложением!
2. Проектирование / охват кода - даже в простейшей форме блок-схемы есть два пути из оператора if и всегда otherwiseиз случая. Нет никаких оснований не включать их в исходный код.

Моя философия всегда довольно проста - оцените наихудший сценарий из двух вариантов и выберите самый безопасный. В случае пустого elseили defaultпредложения, худшие варианты:

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

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

Кроме того, руководящие принципы MISRA-C {см. Профиль для присоединения} рекомендуют defaultпункт для каждогоswitch

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

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

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

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

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

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

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

Если вы действительно уверены, что вас не волнуют другие случаи, по умолчанию: break; // все равно, но значением по умолчанию должно быть что-то вроде default: throw new Error ("непредвиденное значение");

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

Рассмотреть возможность

enum Gender
{
       MALE ,
       FEMALE ;
}

а также

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Я бы сказал, что это лучше, чем случай MALE, случай FEMALE и случай по умолчанию, который вызывает исключение.

Во время фазы тестирования компьютер проверит, является ли g ЖЕЛЕЗНОЙ. Во время производства проверка будет опущена. (Ага микрооптимизация!)

Что еще более важно, вы будете поддерживать свою цель 100% покрытия кода. Если бы вы написали случай по умолчанию, который выдает исключение, как бы вы его протестировали?