Java-Codierungsstandard/Best Practices – Namenskonvention für Break/Continue-Beschriftungen

Question

Manchmal kann eine beschriftete Pause oder Fortsetzung dazu führen, dass der Code viel besser lesbar ist.

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

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

Ich habe mich gefragt, was die gemeinsame Konvention für die Etiketten ist.Alles in Großbuchstaben?erste Kappe?

Answer 1

Wenn Sie Großbuchstaben verwenden müssen, lenkt dies die Aufmerksamkeit auf sie und verhindert, dass sie fälschlicherweise als „Klassen“-Namen interpretiert werden.Auf sie aufmerksam zu machen hat den zusätzlichen Vorteil, dass man die Aufmerksamkeit von jemandem auf sich zieht, der vorbeikommt, Ihren Code umgestaltet und sie entfernt.;)

Answer 2

Ich verstehe nicht, woher diese Regel „Keine Labels verwenden“ kommt.Bei der Ausführung einer nicht-trivialen Schleifenlogik befindet sich der Test zum Unterbrechen oder Fortfahren nicht immer sauber am Ende des umgebenden Blocks.

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

Ja, solche Fälle kommen immer wieder vor.Was schlagen die Leute vor, dass ich es stattdessen verwende?Eine boolesche Bedingung wie diese?

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

Igitt! Das Refactoring als Methode lindert dies auch nicht:

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

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

Sicher ist es etwas hübscher, aber es wird immer noch ein überflüssiger Boolescher Wert herumgereicht.Und wenn die innere Schleife lokale Variablen geändert hat, ist die Umgestaltung in eine Methode nicht immer die richtige Lösung.

Warum sind Sie also alle gegen Etiketten?Nennen Sie mir einige stichhaltige Gründe und praktische Alternativen für den oben genannten Fall.

Answer 3

Die Konvention besteht darin, Etiketten gänzlich zu vermeiden.

Es gibt sehr, sehr wenige triftige Gründe, eine Bezeichnung zum Ausbrechen aus einer Schleife zu verwenden.Ausbrechen ist in Ordnung, aber Sie können die Notwendigkeit zum Ausbrechen ganz beseitigen, indem Sie Ihr Design ein wenig modifizieren.In dem von Ihnen angegebenen Beispiel würden Sie die Abschnitte „Viel Code“ extrahieren und sie in einzelne Methoden mit aussagekräftigen Namen einfügen.

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

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

---

Bearbeiten: nachdem ich den eigentlichen Code gesehen habe (hier drüben), denke ich, dass die Verwendung von Etiketten wahrscheinlich die beste Möglichkeit ist, den Code lesbar zu machen.In den meisten Fällen ist die Verwendung von Etiketten der falsche Ansatz, in diesem Fall halte ich es für in Ordnung.

Answer 4

Der Java-Codestil von Sun scheint die Benennung von Beschriftungen auf die gleiche Weise wie Variablen zu bevorzugen, d. h. Kamel-Schreibweise mit dem ersten Buchstaben in Kleinbuchstaben.

Answer 5

Die Konvention, die ich am häufigsten gesehen habe, ist einfach die Kamel-Schreibweise, wie ein Methodenname ...

myLabel:

Ich habe aber auch Etiketten gesehen, denen ein Unterstrich vorangestellt war

_myLabel:

oder mit Labor...

labSomething:

Anhand der anderen Antworten können Sie jedoch wahrscheinlich erkennen, dass es Ihnen schwer fallen wird, einen Codierungsstandard zu finden, der etwas anderes als „Verwenden Sie keine Etiketten“ sagt.Die Antwort ist dann wohl, dass Sie jeden Stil verwenden sollten, der für Sie sinnvoll ist, solange er konsistent ist.

Answer 6

bzgl Sadies Codebeispiel:

Du gabst

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

Als Beispiel.Du hast einen guten Punkt.Meine beste Vermutung wäre:

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

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

Aber es gäbe Beispiele, bei denen diese Art der Umgestaltung nicht mit der von Ihnen verwendeten Logik übereinstimmt.

Answer 7

Da Bezeichnungen so selten nützlich sind, scheint es keine klare Konvention zu geben.Die Java-Sprachspezifikation enthält ein Beispiel mit Beschriftungen, und diese befinden sich in non_cap.

Aber da sie so selten sind, ist es meiner Meinung nach das Beste, zweimal darüber nachzudenken, ob sie wirklich das richtige Werkzeug sind.

Und wenn sie das richtige Werkzeug sind, machen Sie sie alle groß, damit andere Entwickler (oder später Sie selbst) sie sofort als etwas Ungewöhnliches erkennen.(wie Craig bereits betonte)

Answer 8

Die Konvention/Best Practice wäre immer noch, sie überhaupt nicht zu verwenden und den Code so umzugestalten, dass er mithilfe von extract als Methode besser lesbar ist.

Answer 9

Sie sind eine Art Goto von Java – ich bin mir nicht sicher, ob C# sie hat.Ich habe sie noch nie in der Praxis verwendet. Ich kann mir keinen Fall vorstellen, in dem ihre Vermeidung nicht zu viel besser lesbarem Code führen würde.

Aber wenn es sein muss – ich denke, dass nur Großbuchstaben in Ordnung sind.Die meisten Leute verwenden keine beschrifteten Pausen. Wenn sie also den Code sehen, springen ihnen die Großbuchstaben ins Auge und zwingen sie zu erkennen, was vor sich geht.

Answer 10

Ich weiß, ich sollte keine Etiketten verwenden.

Aber nehmen Sie einfach an, ich habe Code, der durch beschriftete Umbrüche deutlich lesbarer werden könnte. Wie formatiere ich ihn?

Mo, deine Prämisse ist falsch.Die Frage sollte nicht lauten: „Wie formatiere ich sie?“

Ihre Frage sollte lauten: „Ich habe Code, der eine große Menge an Logik in Schleifen enthält – wie mache ich ihn lesbarer?“

Die Antwort auf diese Frage besteht darin, den Code in einzelne, gut benannte Funktionen zu verschieben.Dann brauchen Sie die Pausen überhaupt nicht zu beschriften.