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

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;
}

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

Как вы думаете? Это нормально, чтобы удалить их? Или вы бы держали их за увеличение «правильности»?

Answer 1

Удалить break заявления. Они не нужны, и, возможно, некоторые компиляторы будут выдавать "Недостижимый код" Предупреждения.

Answer 2

Я бы полностью взял другую прихвату. Не возвращайте в середину метода / функции. Вместо этого просто поместите возвращаемое значение в локальной переменной и отправьте его в конце.

Лично я нахожу следующее, чтобы быть более читаемым:

String result = "";

switch (something) {
case 0:
  result = "blah";
  break;
case 1:
  result = "foo";
  break;
}

return result;

Answer 3

Лично я бы удалил возврат и сохранил перерывы. Я бы использовал оператор Switch для назначения значения для переменной. Затем верните эту переменную после оператора Switch.

Хотя это утверждаемая точка, я всегда чувствовал, что хороший дизайн и инкапсуляция означает один путь и один выход. Гораздо легче гарантировать логику, и вы не случайно пропустите код очистки на основе цикломатической сложности вашей функции.

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

Answer 4

Держите перерывы - у вас реже столкнутся с проблемами, если / при редактировании кода позже, если перерывы уже на месте.

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

Answer 5

Удалить их. Это идиоматично вернуться из case заявления, и это «недостижимый код» шум в противном случае.

Answer 6

Я бы удалил их. В моей книге Dead Code, как это следует считаться ошибками, потому что это заставляет вас сделать двойной взять и спросить себя «Как бы я когда-либо казнил эту линию?»

Answer 7

Я обычно пишу код без них. IMO, Dead Code имеет тенденцию указывать на непринужденность и / или отсутствие понимания.

Конечно, я бы также считал что-то вроде:

char const *rets[] = {"blah", "foo", "bar"};

return rets[something];

Редактировать: даже с отредактированным постом, эта общая идея может работать нормально:

char const *rets[] = { "blah", "foo", "bar", "bar", "foo"};

if ((unsigned)something < 5)
    return rets[something]
return "foobar";

В какой-то момент, особенно если входные значения являются редкими (например, 1, 100, 1000 и 10000), вы хотите вместо этого редкого массива. Вы можете реализовать это как дерево, либо на карту достаточно хорошо (хотя, конечно, переключатель по-прежнему работает в этом случае).

Answer 8

Я бы сказал, удалите их и определите ветку по умолчанию:

Answer 9

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

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

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

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

Answer 10

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

Answer 11

Как вы думаете? Это нормально, чтобы удалить их? Или вы бы держали их за увеличение «правильности»?

Это нормально, чтобы удалить их. С использованием return является точно Сценарий, где break не следует использовать.

Answer 12

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

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

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

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

Answer 13

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

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

Answer 14

Я лично склонен терять 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);
}

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

Answer 15

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

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

---

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**;

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

Answer 16

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

Answer 17

Если у вас есть тип кода «lookup», вы можете упаковать предложение коммутатора в методе сам по себе.

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

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;
    }
}

(Yep. Это пространство Gurps ...)

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

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

(На ... в третью? то, что могло быть навязчивым ...)