Разбить случай по умолчанию в коммутаторе

Я немного озадачен тем, когда включаю или не включаю breakпосле последнего случая, часто default.

switch (type) {
    case 'product':

        // Do behavior

        break;
    default:

        // Do default behavior

        break; // Is it considered to be needed?
}

breakв моем понимании единственная цель - остановить выполнение кода через остальную часть регистра switch.

Тогда считается ли более логичным иметь breakпоследнее из-за непротиворечивости или пропустить его из-за breakотсутствия функционального использования вообще? И то и другое логично по-моему.

Это можно в определенной степени сравнить с окончанием .phpфайла ?>. Я никогда не заканчиваю в ?>основном из-за риска вывода пробелов, но можно утверждать, что было бы логично завершить файл.

breakтехнически не требуется после последней альтернативы (что, к вашему сведению, необязательно default: это совершенно законно, а иногда даже полезно ставить defaultветку на первое место); независимо от того, проваливается ли ваш код в конце switchоператора или breaksвыходит в конце его последней ветви, результат будет одинаковым.

Тем не менее, я бы по-прежнему заканчивал каждую ветку, включая последнюю, оператором returnили breakпо трем причинам:

1. Refactorability. Если все ваши ветви заканчиваются на breakили return, вы можете изменить их порядок без изменения значения. Это снижает вероятность того, что при таком переупорядочении будет введена регрессия.
2. Последовательность и наименьший сюрприз. Последовательность говорит, что ваши ветви должны заканчиваться последовательно, если они на самом деле не имеют другого значения. Принцип Наименьшего Сюрприза гласит, что похожие вещи должны выглядеть одинаково. Завершение последней ветви switchблока точно так же, как и предыдущие, выполняет обе функции, что облегчает чтение и понимание. Если вы не укажете явное break, последняя ветвь будет оптически отличаться (что особенно важно для быстрого сканирования), и, чтобы увидеть, что она на самом деле не отличается, читатель должен опуститься до мельчайшего уровня чтения отдельных операторов. ,
3. Защищать себя. Если у вас есть привычка заканчивать все свои switchветви буквой a break, через некоторое время она станет автоматической, и вы с меньшей вероятностью случайно забудете об этом, где это имеет значение. Тренировка себя ожидать breakв конце каждой ветки также помогает обнаруживать пропущенные breakоператоры, что отлично подходит для отладки и устранения неполадок.

Учитывая неоднозначность, которая существует вокруг использования switch-caseв большинстве языков, при его использовании я бы предложил всегда использовать breakвыражение, за исключением случаев, когда оно явно и по замыслу нежелательно .

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

Там нет breakнеобходимости после последнего случая. Я использую слово « последний » (не по умолчанию ), потому что это не обязательно. Случай по умолчанию - последний случай.

switch(x)
{
case 1:
//do stuff
break;

default:
//do default work
break;

case 3:
//do stuff

}

И мы знаем, что break необходимо между двумя последовательными caseс. Иногда я использую if(a!=0)в своем коде для большей читабельности, когда другие ссылаются на мой код. Я могу выбрать для использования if(a), это было бы вопросом моего выбора