Norme de codage Java/meilleures pratiques – convention de dénomination pour les étiquettes de rupture/continuation

Question

Parfois, un break ou un continue étiqueté peut rendre le code beaucoup plus lisible.

OUTERLOOP: for ( ;/*stuff*/; ) {
    //...lots of code

    if ( isEnough() ) break OUTERLOOP;
    //...more code
}

Je me demandais quelle était la convention commune pour les étiquettes.Toutes en majuscules?première casquette ?

Answer 1

Si vous devez les utiliser, utilisez des majuscules, cela attire l'attention sur eux et les évite d'être interprétés à tort comme des noms de « classe ».Attirer l'attention sur eux présente l'avantage supplémentaire d'attirer l'attention de quelqu'un qui viendra refactoriser votre code et le supprimer.;)

Answer 2

Je ne comprends pas d'où vient cette règle "ne pas utiliser d'étiquettes".Lorsque vous effectuez une logique de boucle non triviale, le test à interrompre ou à continuer n'est pas toujours parfaitement à la fin du bloc environnant.

outer_loop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outer_loop;
    //  more code
  }
  //  more code
}

Oui, des cas comme celui-ci arrivent tout le temps.Qu’est-ce que les gens me suggèrent d’utiliser à la place ?Une condition booléenne comme celle-ci ?

for (...) {
  //  some code
  boolean continueOuterLoop = false;
  for (...) {
    //  some code
    if (...) {
      continueOuterLoop = true;
      break;
    }
    //  more code
  }
  if (continueOuterLoop)
    continue;
  //  more code
}

Beurk ! Le refactoriser en tant que méthode ne résout pas ce problème non plus :

boolean innerLoop (...) {
  for (...) {
    //  some code
    if (...) {
      return true;
    }
    //  more code
  }
  return false;
}

for (...) {
  //  some code
  if (innerLoop(...))
    continue;
  //  more code
}

Bien sûr, c'est un peu plus joli, mais cela fait toujours circuler un booléen superflu.Et si la boucle interne modifie les variables locales, la refactoriser en méthode n'est pas toujours la bonne solution.

Alors pourquoi êtes-vous tous contre les étiquettes ?Donnez-moi des raisons solides et des alternatives pratiques pour le cas ci-dessus.

Answer 3

La convention est d’éviter complètement les étiquettes.

Il y a très, très peu de raisons valables d'utiliser une étiquette pour sortir d'une boucle.La rupture est acceptable, mais vous pouvez supprimer le besoin de rompre en modifiant légèrement votre conception.Dans l'exemple que vous avez donné, vous extrairiez les sections « Beaucoup de code » et les placeriez dans des méthodes individuelles avec des noms significatifs.

for ( ;/*stuff*/; ) 
{
    lotsOfCode();

    if ( !isEnough() )
    {
        moreCode();
    }
}

---

Modifier: après avoir vu le code en question (par ici), je pense que l’utilisation d’étiquettes est probablement le meilleur moyen de rendre le code lisible.Dans la plupart des cas, l'utilisation d'étiquettes n'est pas la bonne approche. Dans ce cas, je pense que c'est très bien.

Answer 4

Le style de code Java de Sun semble préférer nommer les étiquettes de la même manière que les variables, c'est-à-dire en casse chameau avec la première lettre en minuscule.

Answer 5

La convention que j'ai le plus vue est simplement le cas de chameau, comme un nom de méthode...

myLabel:

mais j'ai aussi vu des étiquettes préfixées par un trait de soulignement

_myLabel:

ou avec le laboratoire...

labSomething:

Cependant, vous pouvez probablement sentir, à partir des autres réponses, que vous aurez du mal à trouver une norme de codage qui dit autre chose que « Ne pas utiliser d'étiquettes ».La réponse, je suppose, est que vous devez utiliser le style qui vous semble logique, à condition qu'il soit cohérent.

Answer 6

par rapport exemple de code de Sadie:

Vous avez donné

outerloop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outerloop;
    //  more code
  }
  //  more code
}

Par exemple.Vous faites valoir un bon point.Ma meilleure hypothèse serait :

public void lookMumNoLabels() {
  for (...) {
    // some code
    doMoreInnerCodeLogic(...);
  }
}

private void doMoreInnerCodeLogic(...) {
   for (...) {
      // some code
      if (...) return;
   }
}

Mais il y aurait des exemples où ce type de refactorisation ne correspond pas correctement à la logique que vous utilisez.

Answer 7

Comme les étiquettes sont si rarement utiles, il semble qu’il n’existe pas de convention claire.La spécification du langage Java contient un exemple avec des étiquettes et elles sont en non_cap.

Mais comme ils sont si rares, à mon avis, il est préférable de réfléchir à deux fois pour savoir s’ils sont vraiment le bon outil.

Et s'il s'agit du bon outil, mettez-les en majuscules afin que les autres développeurs (ou vous-même plus tard) les réalisent immédiatement comme quelque chose d'inhabituel.(comme Craig l'a déjà souligné)

Answer 8

La convention/meilleure pratique serait toujours de ne pas les utiliser du tout et de refactoriser le code pour qu'il soit plus lisible en utilisant l'extrait comme méthode.

Answer 9

Ils sont en quelque sorte le goto de Java - je ne sais pas si C# les a.Je ne les ai jamais utilisés dans la pratique, je ne vois pas de cas où les éviter n'entraînerait pas un code beaucoup plus lisible.

Mais si vous devez le faire, je pense que toutes les majuscules sont ok.La plupart des gens n'utilisent pas de coupures étiquetées, donc lorsqu'ils voient le code, les majuscules leur sautent dessus et les forcent à comprendre ce qui se passe.

Answer 10

Je sais, je ne devrais pas utiliser d'étiquettes.

Mais supposons simplement que j'ai du code qui pourrait gagner beaucoup en lisibilité grâce aux pauses étiquetées, comment puis-je les formater.

Mo, ta prémisse est fausse.La question ne devrait pas être « comment puis-je les formater ? »

Votre question devrait être "J'ai du code qui contient une grande quantité de logique à l'intérieur de boucles - comment puis-je le rendre plus lisible ?"

La réponse à cette question est de déplacer le code dans des fonctions individuelles bien nommées.Ensuite, vous n'avez pas du tout besoin d'étiqueter les pauses.