думать им приходилось обо всем разом .
И о портабельности, и о компактности получаемого кода, и об эффективности как результата компиляции, так и работы программиста.

Может быть ты не поверишь, но и о культуре сопровождения кода в большой корпорации тоже.
У Кернигана можно найти упоминание о том, произвольность местоположения default была выбрана сознательно ,
в расчете на то, что при возникновении необходимости дописывать что-то в существующий switch,
корпоративные программисты хотели бы и будут размещать новые ветки ниже уже существующих,
а не произвольным образом втыкивать их между старыми, превращая старый код в неузнаваемый.



А в чем резкость?
Если не является резкостью отсутствие break после каждой ветки, почему его отсутствие после default -
обычной, по сути метки, за малой оговоркой, среди прочих - смущает?
Все как для прочих меток - может быть break, а может и нет.

Стартовый код прост как палка: для набора значений, известных как "хорошие случаи" просто goto на метку return True.
Иначе провести доп проверку (с побочным действием) и решить - true оно return или нет.

При этом нет сомнения, что студент за такой код должен быть немедленно отчислен.
:))

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

А как это переводится на человечий язык?
неужто кто-то из компиляторов двоичный поиск по таблице значений реализует?

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

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

Это сейчас в моде "рефакторинг" до степени не узнавания родной мамой со свистелками и перделками.
А в традиционной промышленности, после того, как изначальный код написан и программист уволился -
никто не знает , что там делается.

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

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

petrav,

"промышленная система" и "команда" - это антонимичные понятия, по Гамбурскому счёту.

для работы с "промышленной системой" по определению годится произвольный выловленный из уличной толпы человек.
Промышленный прикладной программист не должен быть образован, иначе он работать не сможет .
Сразу, вместо работы, начнёт switch-и рефакторить.

Когда по любой причине произвольно схваченный за рукав не годится - объявляется, что существует "команда",
которой нужны "штыки" (в смысле обученные солдаты, если и не умеющие пользоваться, то хотя бы представляющие
правдоподобно, что значит слово "штык").
Бывает, когда "команда" уходит, то, что после неё остаётся, автоматически превращается в обыкновенный "промышленный код".

Буквально то, что написано.

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

Обоснование уменьшения количества ошибок от увеличения количества дум вызывает большой скепсис,
а количество строк кода от увеличения дум уменьшается несомненно.
Когда человек думает, он код не пишет, по крайней мере рабочий код.
В "промышленности" нет задачи иметь в штате "умного человека", но есть задача выпустить "много кода".
Как это обеспечить, в условиях, когда роботы еще не заменили человека-программиста?

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

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

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

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

Вот и всё, приблизительно, если не сильно растекаться по древу.