Переключити перехід заяви на випадок ... чи слід це дозволити? [зачинено]

До тих пір, як я пам'ятаю, я уникав використання переключення оператора перемикання. Насправді я не можу згадати, щоб він коли-небудь входив у мою свідомість як можливий спосіб робити речі, оскільки це було просвердлено мені в голову рано, що це було не що інше, як помилка в заяві перемикача. Однак сьогодні я зіткнувся з деяким кодом, який використовує його при розробці дизайну, і мене одразу задало питання, що всі в громаді думають про пропуск транзакції.

Це щось, що мова програмування явно не повинна дозволити (як, наприклад, C #, хоча вона забезпечує вирішення) або це особливість будь-якої мови, достатньо потужної, щоб залишити її в руках програміста?

Редагувати: Я не був достатньо конкретним щодо того, що я мав на увазі під пропадом. Я багато використовую цей тип:

    switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something
            break;
        case 2:
        case 3:
        case 4:
            // Do something
            break;
   }

Однак мене турбує щось подібне.

   switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something, but fall through to the other cases
            // after doing it.

        case 2:
        case 3:
        case 4:
            // Do something else.
            break;
   }

Таким чином, коли випадок дорівнює 0, 1, він буде робити все в операторі комутатора. Я бачив це за допомогою дизайну, і я просто не знаю, чи згоден я, що заяви переключення повинні використовуватися таким чином. Я думаю, що перший приклад коду дуже корисний і безпечний. Друга видається небезпечною.

Це може залежати від того, що ви вважаєте переломним. Я все в порядку з такими речами:

switch (value)
{
  case 0:
    result = ZERO_DIGIT;
    break;

  case 1:
  case 3:
  case 5:
  case 7:
  case 9:
     result = ODD_DIGIT;
     break;

  case 2:
  case 4:
  case 6:
  case 8:
     result = EVEN_DIGIT;
     break;
}

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

І будь ласка, зауважте, що я використовую визначення C ++ поширених питань "зла"

Це меч з двома кінцями. Іноді це дуже корисно, але часто небезпечно.

Коли це добре? Коли ви хочете, щоб 10 справ оброблялися однаково ...

switch (c) {
  case 1:
  case 2:
            ... Do some of the work ...
            /* FALLTHROUGH */
  case 17:
            ... Do something ...
            break;
  case 5:
  case 43:
            ... Do something else ...
            break;
}

Єдине правило, яке мені подобається, це те, що якщо ви коли-небудь займаєтесь фантазією, коли ви виключаєте перерву, вам потрібен чіткий коментар / * ПІДТРИМКА * /, щоб вказати, що це був ваш намір.

Ви чули про пристрій Даффа ? Це чудовий приклад використання перемикача комутатора.

Це функція, якою можна користуватися, і нею можна зловживати, як і майже всі мовні функції.

Проникнення - це справді зручна річ, залежно від того, що ти робиш. Розглянемо цей акуратний і зрозумілий спосіб впорядкувати варіанти:

switch ($someoption) {
  case 'a':
  case 'b':
  case 'c':
    // Do something
    break;

  case 'd':
  case 'e':
    // Do something else
    break;
}

Уявіть, що ви робите це за допомогою if / else. Це був би безлад.

Це може бути дуже корисним кілька разів, але в цілому жодне проникнення не є бажаною поведінкою. Пропуск повинен бути дозволений, але не неявний.

Приклад оновлення старих версій деяких даних:

switch (version) {
    case 1:
        // Update some stuff
    case 2:
        // Update more stuff
    case 3:
        // Update even more stuff
    case 4:
        // And so on
}

Я б хотів, щоб інший синтаксис для резервних копій в комутаторах, щось на кшталт, помилка ..

switch(myParam)
{
  case 0 or 1 or 2:
    // Do something;
    break;
  case 3 or 4:
    // Do something else;
    break;
}

Примітка. Це може бути можливим із перерахунками, якщо ви задекларуєте всі випадки вашого переліку за допомогою прапорів, правда? Це теж не так погано звучить; справи можуть (повинні?) дуже вже входити до вашого переліку.

Можливо, це був би приємний випадок (не призначений каламбур) для вільного інтерфейсу з використанням методів розширення? Щось на кшталт помилки ...

int value = 10;
value.Switch()
  .Case(() => { /* Do something; */ }, new {0, 1, 2})
  .Case(() => { /* Do something else */ } new {3, 4})
  .Default(() => { /* Do the default case; */ });

Хоча це, мабуть, ще й менш читабельно: P

Як і будь-що: якщо використовувати його обережно, це може бути елегантним інструментом.

Однак, я вважаю, що недоліки більш ніж виправдовують його не використовувати і, нарешті, більше не дозволяти (C #). Серед проблем:

• легко «забути» перерву
• не завжди очевидно, що для тех, хто підтримує код , пропущений розрив був навмисним

Добре використовувати перемикач / випадок корпусу:

switch (x)
{
case 1:
case 2:
case 3:
 Do something
 break;
}

Використання перемикача / корпусу, що проходить через Baaaaad :

switch (x)
{
case 1:
    Some code
case 2:
    Some more code
case 3:
    Even more code
    break;
}

Це можна переписати, використовуючи if / else конструкції без втрат на мою думку.

Моє остаточне слово: тримайтеся подалі від міток справи, що пропускаються, як у поганому прикладі, якщо ви не підтримуєте застарілий код, де цей стиль використовується і добре зрозумілий.

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

Де б я не користувався, я гарантую, що він коментується належним чином:

switch($var) {
    case 'first':
        // Fall-through
    case 'second':
        i++;
        break;
 }

Використовувати пропуск, як у вашому першому прикладі, явно добре, і я б не вважав це справжнім провалом.

Другий приклад небезпечний і (якщо не коментується широко) неочевидний. Я вчу своїх студентів не користуватися такими конструкціями, якщо вони не вважають, що варто докладати зусиль, щоб виділити йому блок коментарів, який описує, що це навмисне проникнення, і чому це рішення краще, ніж альтернативи. Це перешкоджає неохайному використанню, але все ж робить це дозволеним у тих випадках, коли він звик до переваги.

Це більш-менш рівнозначно тому, що ми робили в космічних проектах, коли хтось хотів порушити стандарт кодування: вони повинні були подати заяву про видачу (і мене покликали проконсультувати щодо постанови).

Мені не подобається, що мої switchзаяви провалюються - це занадто схильний до помилок і важко читати. Єдиним винятком є ​​те, коли кілька caseзаяв роблять точно те саме.

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

У деяких випадках використання пропусків - це лінь з боку програміста - вони могли використовувати ряд || наприклад, але натомість використовуйте ряд випадків перемикання «все-все».

Попри це, я вважаю, що вони особливо корисні, коли я знаю, що в підсумку мені знадобляться варіанти (наприклад, у відповіді меню), але ще не застосовано всіх варіантів. Крім того, якщо ви робите пропуск для обох "a" і "A", я вважаю, що набагато чистіше використовувати перехідний перемикач, ніж з'єднання if оператор.

Це, мабуть, питання стилю та того, як думають програмісти, але я, як правило, не люблю видаляти компоненти мови в ім'я "безпеки" - саме тому я схильний до C та його варіантів / нащадків більше, ніж, скажімо, Java. Мені подобається вміти маніпулювати навколо вказівниками тощо, навіть коли у мене немає «причин».

Прохідність повинна використовуватися лише тоді, коли вона використовується як таблиця стрибків у блок коду. Якщо є якась частина коду з безумовною перервою перед більшістю випадків, усі групи справ повинні закінчуватися таким чином.

Все інше - «зло».