Переключение оператора с возвратами - правильность кода

Question

Допустим, у меня есть код на C с примерно такой структурой:

switch (something)
{
    case 0:
      return "blah";
      break;

    case 1:
    case 4:
      return "foo";
      break;

    case 2:
    case 3:
      return "bar";
      break;

    default:
      return "foobar";
      break;
}

Теперь очевидно, что "break" не нужны для правильной работы кода, но это выглядит как плохая практикаесли я не положу их туда мне.

Что ты думаешь?Это нормально, чтобы удалить их?Или вы бы сохранили их для большей «правильности»?

Answer 1

Не лучше ли иметь массив с

arr[0] = "blah"
arr[1] = "foo"
arr[2] = "bar"

и делать return arr[something];?

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

Answer 2

Интересно. Похоже, что большинство из этих ответов согласны с тем, что избыточный оператор break является ненужным беспорядком. С другой стороны, я прочитал оператор break в переключателе как «закрытие» дела. case блоки, которые не заканчиваются на break, имеют тенденцию выпадать на меня как потенциальное падение из-за ошибок.

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

Так что избавьтесь от break, следующего за return.

NB: все это игнорирует, является ли нарушение единого правила входа / выхода хорошей идеей или нет. Что касается этого, у меня есть мнение, что, к сожалению, меняется в зависимости от обстоятельств ...

Answer 3

Если у вас есть код типа «поиск», вы можете упаковать условие switch-case в метод сам по себе.

У меня есть несколько таких в системе «хобби», для которой я разрабатываюПриколы:

private int basePerCapitaIncomeRaw(int tl) {
    switch (tl) {
        case 0:     return 7500;
        case 1:     return 7800;
        case 2:     return 8100;
        case 3:     return 8400;
        case 4:     return 9600;
        case 5:     return 13000;
        case 6:     return 19000;
        case 7:     return 25000;
        case 8:     return 31000;
        case 9:     return 43000;
        case 10:    return 67000;
        case 11:    return 97000;
        default:    return 130000;
    }
}

(Да. Это пробел GURPS ...)

Я согласен с другими, что в большинстве случаев вам следует избегать более одного возврата в метод, и я признаючто этот мог бы быть лучше реализован как массив или что-то еще.Я только что обнаружил, что switch-case-return довольно легко соответствует таблице поиска с соотношением 1: 1 между входом и выходом, как и в предыдущем примере (в ролевых играх их полно, я уверен, что они существуют в других«business»): D

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

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

Answer 4

Код выхода в одной точке.Это обеспечивает лучшую читаемость кода.Добавление операторов возврата (несколько выходов) между ними затруднит отладку.

Answer 5

Я думаю, что * перерыв * с есть цель.Это чтобы сохранить «идеологию» программирования.Если мы просто «запрограммируем» наш код без логической последовательности, возможно, он будет доступен для чтения сейчас, но попробуйте завтра.Попробуйте объяснить это своему боссу.Попробуйте запустить его на Windows 3030.

Блин, идея очень проста:

---

Switch ( Algorithm )
{

 case 1:
 {
   Call_911;
   Jump;
 }**break**;
 case 2:
 {
   Call Samantha_28;
   Forget;
 }**break**;
 case 3:
 {
   Call it_a_day;
 }**break**;

Return thinkAboutIt?1:return 0;

void Samantha_28(int oBed)
{
   LONG way_from_right;
   SHORT Forget_is_my_job;
   LONG JMP_is_for_assembly;
   LONG assembly_I_work_for_cops;

   BOOL allOfTheAbove;

   int Elligence_says_anyways_thinkAboutIt_**break**_if_we_code_like_this_we_d_be_monkeys;

}
// Sometimes Programming is supposed to convey the meaning and the essence of the task at hand. It is // there to serve a purpose and to keep it alive. While you are not looking, your program is doing  // its thing. Do you trust it?
// This is how you can...
// ----------
// **Break**; Please, take a **Break**;

/ * Просто небольшой вопрос.Сколько кофе вы выпили, читая выше?IT ломает систему иногда * /

Answer 6

Лично я склонен терять break с. Возможно, одним из источников этой привычки являются процедуры программирования окна для приложений Windows:

LRESULT WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
        case WM_SIZE:
            return sizeHandler (...);
        case WM_DESTROY:
            return destroyHandler (...);
        ...
    }

    return DefWindowProc(hwnd, uMsg, wParam, lParam);
}

Лично я нахожу этот подход намного проще, лаконичнее и гибче, чем объявлять возвращаемую переменную, установленную каждым обработчиком, и возвращать ее в конце. При таком подходе break являются избыточными и поэтому должны идти - они не служат никакой полезной цели (синтаксически или IMO визуально) и только раздувают код.

Answer 7

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

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