instruction Switch avec des rendements - correction de code

Question

LET dire de moi avons code en C avec environ cette structure:

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

De toute évidence, la « rupture » s ne sont pas nécessaires pour que le code de fonctionner correctement, mais il sorte de ressemble à une mauvaise pratique si je ne les mets pas là pour moi.

Que pensez-vous? Est-il bien beau de les enlever? Ou vous les garder pour une meilleure « décision correcte »?

Answer 1

Supprimer les énoncés de break. Ils ne sont pas nécessaires et peut-être certains compilateurs émettront "Code Inaccessible" avertissements .

Answer 2

je prendrais une tout autre tactique. Ne retournez pas au milieu de la méthode / fonction. Au lieu de cela, il suffit de mettre la valeur de retour dans une variable locale et l'envoyer à la fin.

Personnellement, je trouve ce qui suit pour être plus lisible:

String result = "";

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

return result;

Answer 3

Personnellement, je supprimerais les retours et garder les pauses. Je voudrais utiliser l'instruction switch pour attribuer une valeur à une variable. Revenez ensuite cette variable après l'instruction switch.

Bien que ce soit un point discutable, je me suis toujours senti que les moyens de bonne conception et d'encapsulation d'une manière et d'une sortie. Il est beaucoup plus facile de garantir la logique et vous ne manquez pas le code accidentellement nettoyage basé sur la complexité cyclomatique de votre fonction.

Une exception:. De retour au début est correct si un paramètre mauvais est détecté au début d'une fonction - avant que les ressources sont acquises

Answer 4

Gardez les pauses -. Vous êtes moins susceptibles d'avoir des ennuis si / lorsque vous modifiez le code plus tard si les pauses sont déjà en place

Cela dit, il est considéré par beaucoup (y compris moi) être une mauvaise pratique de revenir à partir du milieu d'une fonction. Idéalement, une fonction doit avoir un point d'entrée et un point de sortie.

Answer 5

les supprimer. Il est idiomatiques de retourner des déclarations de case, et « Code inatteignable » bruit autrement.

Answer 6

Je les supprimer. Dans mon livre, code mort comme ça devrait être considérées comme des erreurs parce qu'il vous fait faire une double-prise et vous vous demandez « Comment pourrais-je exécuter jamais cette ligne? »

Answer 7

Je normalement écrire le code sans eux. OMI, code mort tend à indiquer le laisser-aller et / ou le manque de compréhension.

Bien sûr, je voudrais aussi envisager quelque chose comme:

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

return rets[something];

Edit: même avec le poste de modification, cette idée générale peut fonctionner correctement:

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

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

À un moment donné, surtout si les valeurs d'entrée sont rares (par exemple, 1, 100, 1000 et 10000), on veut à la place d'un tableau creux. Vous pouvez mettre en œuvre que ce soit un arbre ou une carte bien raisonnable (si, bien sûr, un commutateur fonctionne toujours dans ce cas aussi bien).

Answer 8

Je dirais les supprimer et définir une valeur par défaut:. Branche

Answer 9

Ne serait-il préférable d'avoir un tableau avec

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

et faire return arr[something];?

S'il est au sujet de la pratique en général, vous devez conserver les déclarations de break dans le commutateur. Dans le cas où vous n'avez pas besoin de déclarations return à l'avenir, il diminue le risque qu'il tombe jusqu'à la prochaine case.

Answer 10

Pour « décision correcte », entrée unique, les blocs de sortie unique sont une bonne idée. Au moins, ils étaient quand je faisais mes études en informatique. Donc, je déclarerais probablement une variable, lui assigner dans le commutateur et revenir une fois à la fin de la fonction

Answer 11

  

Que pensez-vous? Est-il bien beau de les enlever? Ou vous les garder pour une meilleure "décision correcte"?

Il est bon de les enlever. L'utilisation return est exactement le scénario où break ne doit pas être utilisé.

Answer 12

Intéressant. Le consensus de la plupart de ces réponses semble que l'instruction break redondante est l'encombrement inutile. D'autre part, je lis la déclaration de break dans un commutateur comme la « fermeture » d'un cas. blocs case qui ne finissent pas dans un break ont tendance à sauter à moi comme risque de chute si des bugs.

Je sais que ce n'est pas comment il est quand il y a un return au lieu d'un break, mais de faire de la lecture «les blocs de cas dans un commutateur mes yeux, donc je préférerais, que chaque case être jumelé à un break. Mais de nombreux statisticiens ne se plaignent du break après une return étant superflu / injoignable, et apparemment je semblent être en minorité de toute façon.

Alors se débarrasser de la break suite à une return.

NB: tout cela ne tient pas compte s'il ne respecte pas la règle d'entrée / sortie unique est une bonne idée ou non. En ce qui concerne ce qui va, j'ai une opinion que, malheureusement, les changements en fonction des circonstances ...

Answer 13

Je dis les supprimer. Si votre code est si illisible que vous devez tenir des pauses là-dedans « pour être du bon côté », vous devriez revoir votre style de codage:)

Aussi j'ai toujours préféré ne pas mélanger les pauses et les retours dans l'instruction switch, mais le bâton avec l'un d'eux.

Answer 14

je tends personnellement à perdre les breaks. Peut-être une source de cette habitude est de la programmation des procédures de fenêtre pour les applications 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);
}

Je trouve personnellement cette approche beaucoup plus simple, concise et plus souple que la déclaration d'un ensemble variable de retour par chaque gestionnaire, puis retour à la fin. Compte tenu de cette approche, les breaks sont redondants et devraient donc aller - ils ne servent à rien (syntaxiquement ou visuelle de l'OMI) et seulement ballonnement le code

.

Answer 15

Je pense que le * break * s sont là pour un but. Il est de maintenir la « idéologie » de la programmation en vie. Si nous voulons simplement « programme » de notre code sans cohérence logique, il serait peut-être facile à lire pour vous maintenant, mais essayez de demain. Essayez d'expliquer à votre patron. Essayez de l'exécuter sous Windows 3030.

Bleah, l'idée est très simple:

---

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

/ * Juste une question mineure si. Combien avez-vous eu du café tout en lisant ce qui précède? IL. Pauses le système parfois * /

Answer 16

Code de sortie à un moment donné. Cela offre une meilleure lisibilité au code. Ajout d'instructions de retour (des sorties multiples) entre fera le débogage difficile.

Answer 17

Si vous avez le type de code "de recherche", vous pouvez emballer la clause switch-case dans une méthode par lui-même.

J'ai quelques-unes de ces derniers dans un système de « passe-temps » que je développe pour le plaisir:

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

(Ouais. C'est un espace GURPS ...)

Je suis d'accord avec les autres que vous devriez éviter dans la plupart des cas plus d'un retour dans une méthode, et je reconnais que celui-ci aurait pu être mieux mis en œuvre comme un tableau ou autre chose. Je viens de trouver switch-case-retour à être un match assez facile à une table de consultation avec une 1-1 corrélation entre l'entrée et la sortie, comme la chose ci-dessus (jeux de rôle sont pleins d'entre eux, je suis sûr qu'ils existent suis dans d'autres "entreprises", ainsi): D

Par contre, si le cas l'article est plus complexe, ou quelque chose qui se passe après l'interrupteur-déclaration, je ne recommande pas d'utiliser le rendement en elle, mais plutôt définir une variable dans le commutateur, la fin avec une pause et renvoyer la valeur de la variable à la fin.

(Sur la ... troisième? La main ... vous pouvez toujours factoriser un interrupteur dans sa propre méthode ... Je doute qu'il aura un effet sur la performance, et il ne me surprendrait pas si les compilateurs modernes pourraient même reconnaître comme quelque chose qui pourrait être inline ...)