"switch case" — плохо?

Question

[MagDarkElf]

Есть какое-то неписанное правило не использовать switch case в C#?
Периодически встречаю в коде стопку if или тернарники вложенные в место которого можно было бы использовать swich case

Comments

[Алек Оним]

нет такого правила:-/ всё от ситуации зависит.

Answer 1

[Espleth]

Я вам могу такой код скинуть, что вы что там не только о switch case забудете, а о синтаскическом сахаре вообще.
Как вы думаете, этот код будет показателем того, что синтаксический сахар - это плохо?
Я думаю суть вы поняли. Где-то удобнее использовать if-else, где-то switch-case. Кто-то просто не любит switch-case по каким-то там своим причинам.
Главное что бы не было такого, а то я видел уже как-то, причем в не самом маленьком проекте:

switch (*bool переменная*)
{
    case true:
        *действия*
    break;
}

Answer 2

[Алексей Павлов]

Конечно, если свич улучшит код, то нужно его использовать. Пример со стопкой if-ов - тот самый случай. Но свич не всегда может быть применим.
Но иногда бывает так, что, хоть и можно сделать свичем, но лучше сделать условием, например, условие if (a>10 && a<=20) лучше, чем взять десять кейсов.

P.S. Я как-то делал одну программу - эмулятор процессора, с выполнением пользовательского кода на ассемблере. Тот процессор имеет около сотни инструкций, и я сделал 100+ кейсов, для каждой инструкции в кейсе вызывался метод. В принципе, было достаточно удобно, я разделил кейсы на группы, и разделял их комментариями (чтобы удобнее искать по коду). Но сейчас я сделал бы по-другому - я сделал бы иерархию классов, и вызывал бы обработчик с помощью чего-то подобного: Processor.Execute(instruction), и не нужно было бы делать сотню кейсов.
(Это было в 2004-м году, писал на Delphi.)

Answer 3

[Станислав Макаров]

О неписанных правилах по написанию какого-либо кода нужно уточнять сначала у того, кто этот код писал или кто его поддерживает сейчас. У конкретного разработчика/команды могут быть свои неписанные правила, которые нужны лично им.
А сам switch используется достаточно часто, чтобы не считать его злом. Уж гораздо чаще, чем goto. Тем более, switch в шарпе гораздо "безопаснее", чем в том же С++, например компилятор следит, чтобы вы поставили break, если у вас есть код после case.
Почитайте код популярных библиотек на codeplex или гитхабе, чтобы самому все увидеть.

Answer 4

[Дмитрий Ковальский]

Как сказали коллеги switch-case не всегда применим. Основное принцип когда switch-case оправдан - 1)у вас МНОГО(больше 3) наборов инструкций в зависимости от значения параметра. 2) Проверяется строгое равенство параметра и его значений. Если логика сложнее( нестрогое равенство или несколько различных проверок различных параметров) - должен применяться if else. А если совсем углубляться в недра ООП - есть такие вещи как наследование и перегрузка методов. Т.е. вы напишете someObject.someMethod() , а логика будет определяться полиморфно, но это уже совсем другая история.

Comments

[Алек Оним]

извините, перечитал ваш ответ пару раз, но так и не понял, к чему тут слова про недра ООП и т.д. может быть вы поясните?:)

[Алексей Павлов]

Алек Оним: посмотрите P.S. в моём ответе

[Дмитрий Ковальский]

Алек Оним: Вы не описали собственно ситуацию вашу. Для некоторых задач логичнее и красивее хренячить иерархию классов с переопределением методов, паттернами и прочими фичами ООП.

[Алек Оним]

Алексей Павлов: логично
Дмитрий Ковальский: я не автор вопроса:) но согласен, что для некоторых задач лучше так, просто мне показалось, что вы достаточно резко перешли к ООП в своём ответе.

Answer 5

[Melz]

switch визуально легче читается тк сразу понятна и переменная и что с ней происходит. Легко изменять.
Плюс кодогенерация довольно хорошо работает на вещах типа Enum.

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

Еще можно делать компактные конечные автоматы (FSM).

case "3":
case "large":
    cost += 50;
    goto case "1";

Comments

[Дмитрий Ковальский]

Я не знаю на каком языке вы пишете, но если говорить про .NET - goto во многих командах это повод лишить премии и подкинуть седых волос сеньору.

[Melz]

Дмитрий Ковальский: В switch - можно т.к. в C# нет классического "fallthrough". Грубо говоря в других языках break не обязателен. И goto в C# не позволит вам прыгать куда хочется. Сениор вас похвалит т.к. альтернатива как правило 10 вложенных if-ов которые совершенно невозможно читать.

[Михаил]

Melz: а что делает ваш код в данном случае? При какой задаче такое вообще можно применить?)

[Melz]

Михаил: Ну тк получается конечный автомат, а большинство видят их в первый и последний раз в универе... довольно мало применений ) Я вот писал кликеры для игрушек (парсеры тоже, но сейчас все с API), для такого размера городить настоящий ООП не имело смысла.
Те у меня 15 известных состояний, как я туда попал не важно, известные дальнейшие шаги захардкодены, опросил мир и пошел дальше по дереву. Просто и сердито.
Хотя сейчас такая концепция зайдет разве что на raspberry pi, на C# диодиками помигать ))

Answer 6

[Михаил]

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