Beschriftete Schleifen werden durch Refactoring entfernt

Question

Nachdem ich davon überzeugt war, dass markierte Pausen/Fortsetzungen ein völliges „Nichts“ sind Hier, ich brauche Hilfe, um die Beschriftung aus meinem Code zu entfernen.

Ich habe eine quadratische Matrix und einen Vektor mit der gleichen Länge.Der Vektor enthält bereits einige Werte und abhängig von den Werten in der Matrix wird der Vektor in der Schleife geändert.

Ich hoffe, das Codefragment ist grundsätzlich verständlich ...

vectorLoop:
for( int idx = 0; idx < vectorLength; idx++) {
    if( conditionAtVectorPosition( v, idx ) ) continue vectorLoop;

    matrixLoop:
    for( rowIdx = 0; rowIdx < n; rowIdx++ ) {
        if( anotherConditionAtVector( v, rowIdx ) ) continue matrixLoop;
        if( conditionAtMatrixRowCol( m, rowIdx, idx ) ) continue vectorLoop;
    }
    setValueInVector( v, idx );
}     

Bitte überzeugen Sie mich davon, dass es eine besser lesbare/bessere Version ohne Beschriftung gibt.

Answer 1

Blick auf die bisher vorgestellten Lösungen:

• Sie sehen alle weniger lesbar aus als das Original, da mehr Code für den Mechanismus des Codes aufgewendet wird als für den Algorithmus selbst

• Einige davon sind kaputt oder waren es schon, bevor sie bearbeitet wurden.Am verheerendsten ist die Tatsache, dass die Leute ziemlich intensiv darüber nachdenken müssen, wie sie den Code ohne Labels schreiben können, ohne dass etwas kaputt geht.

• Bei einigen kommt es zu Leistungseinbußen, wenn derselbe Test zweimal ausgeführt wird, was nicht immer trivial ist.Die Alternative dazu ist das Speichern und Weitergeben von Booleschen Werten, was hässlich wird.

• Den relevanten Teil des Codes in eine Methode umzugestalten, ist praktisch ein No-Op:Es ordnet die Anordnung des Codes in der Datei neu an, hat jedoch keinen Einfluss auf die Art und Weise, wie er ausgeführt wird.

All dies lässt mich glauben, dass die Bezeichnung zumindest im Fall dieser Frage, wie sie formuliert ist, die richtige Lösung ist und nicht umgestaltet werden muss.Sicherlich gibt es Fälle, in denen Etiketten falsch verwendet werden und umgestaltet werden sollten.Ich denke einfach nicht, dass es als eine unumstößliche Regel betrachtet werden sollte.

Answer 2

@Patrick Sie gehen davon aus, dass setValueInVector( v, idx );am Ende der zweiten Schleife ist in Ordnung.Wenn der Code identisch sein soll, muss er logischerweise etwa so umgeschrieben werden:

for( int idx = 0; idx 

Answer 3

Ganz einfach, mein guter Mann.

for( int idx = 0; idx < vectorLength; idx++) {
  if( conditionAtVectorPosition( v, idx ) ) continue;

  for( rowIdx = 0; rowIdx < n; rowIdx++ ) {
    if( anotherConditionAtVector( v, rowIdx ) ) continue;
    if( conditionAtMatrixRowCol( m, rowIdx, idx ) ) break;
  }
  if( !conditionAtMatrixRowCol( m, rowIdx, idx ) )
    setValueInVector( v, idx );
}

BEARBEITEN:Ganz richtig, du bist Anders.Ich habe meine Lösung bearbeitet, um dies ebenfalls zu berücksichtigen.

Answer 4

Vom Lesen Ihres Codes.

• Mir ist aufgefallen, dass Sie die ungültigen Vektorpositionen bei „conditionAtVectorPosition“ entfernt haben und dann die ungültigen Zeilen bei „otherConditionAtVector“ entfernt haben.
• Es scheint, dass die Überprüfung von Zeilen bei anotherConditionAtVector überflüssig ist, da anotherConditionAtVector unabhängig vom Wert von idx nur vom Zeilenindex abhängt (vorausgesetzt, anotherConditionAtVector hat keine Nebenwirkungen).

So können Sie Folgendes tun:

• Rufen Sie zuerst die gültigen Positionen mit „conditionAtVectorPosition“ ab (dies sind die gültigen Spalten).
• Rufen Sie dann die gültigen Zeilen mit anotherConditionAtVector ab.
• Verwenden Sie abschließend „conditionAtMatrixRowCol“ mit den gültigen Spalten und Zeilen.

Ich hoffe das hilft.

Answer 5

@Nicolas

Einige davon sind kaputt oder waren es schon, bevor sie bearbeitet wurden.Am verdammten ist die Tatsache, dass die Leute ziemlich hart darüber nachdenken müssen, wie man den Code ohne Etiketten schreibt und nichts brechen muss.

Ich bin anderer Meinung:Einige von ihnen sind gebrochen, weil es schwierig ist, das Verhalten des ursprünglichen Algorithmus herauszufinden.

Mir ist klar, dass es subjektiv ist, aber ich habe keine Probleme, den ursprünglichen Algorithmus zu lesen.Es ist kürzer und klarer als die vorgeschlagenen Ersetzungen.

Alle Refactorings in diesem Thread emulieren das Verhalten eines Labels mithilfe anderer Sprachfunktionen – als würden Sie den Code in eine Sprache portieren, die keine Labels hat.

Answer 6

Bei einigen kommt es zu Leistungseinbußen, wenn derselbe Test zweimal ausgeführt wird, was nicht immer trivial ist.Die Alternative dazu ist das Speichern und Weitergeben von Booleschen Werten, was hässlich wird.

Die Leistungseinbußen sind gering.Allerdings stimme ich zu, dass es keine gute Lösung ist, einen Test zweimal durchzuführen.

Ich glaube, die Frage war, wie man die Etiketten entfernt, und nicht, wie man den Algorithmus optimiert.Es schien mir, dass der ursprüngliche Verfasser nicht wusste, wie man die Schlüsselwörter „continue“ und „break“ ohne Beschriftung verwendet, aber natürlich könnten meine Annahmen falsch sein.

Was die Leistung angeht, gibt der Beitrag keine Informationen über die Implementierung der anderen Funktionen. Soweit ich weiß, könnten sie die Ergebnisse also genauso gut über FTP herunterladen, als dass sie aus einfachen, vom Compiler inline eingebetteten Berechnungen bestehen.

Allerdings ist es theoretisch nicht optimal, denselben Test zweimal durchzuführen.

BEARBEITEN:Bei genauerer Betrachtung handelt es sich bei dem Beispiel eigentlich nicht um eine schreckliche Verwendung von Etiketten.I stimme zu „goto ist ein Nein-Nein“, aber nicht wegen Code wie diesem.Die Verwendung von Labels hat hier keinen nennenswerten Einfluss auf die Lesbarkeit des Codes.Natürlich sind sie nicht erforderlich und können leicht weggelassen werden, aber sie nicht zu verwenden, nur weil „die Verwendung von Labels schlecht ist“, ist in diesem Fall kein gutes Argument.Schließlich macht das Entfernen der Beschriftungen den Code nicht viel besser lesbar, wie andere bereits kommentiert haben.

Answer 7

Bei dieser Frage ging es nicht um die Optimierung des Algorithmus – aber trotzdem danke ;-)

Als ich es schrieb, betrachtete ich das beschriftete Weiter als eine lesbare Lösung.

Ich habe SO a gefragt Frage über die Konvention (die Beschriftung in Großbuchstaben schreiben oder nicht) für Beschriftungen in Java.

Grundsätzlich sagte mir jede Antwort: „Benutze sie nicht – es gibt immer einen besseren Weg!“umgestalten!".Deshalb habe ich diese Frage gestellt, um nach einer besser lesbaren (und daher besseren?) Lösung zu fragen.

Bisher bin ich von den bisher vorgestellten Alternativen nicht ganz überzeugt.

Bitte verstehen Sie mich nicht falsch.Etiketten sind meistens böse.

Aber in meinem Fall sind die bedingten Tests ziemlich einfach und der Algorithmus stammt aus einer mathematischen Arbeit und wird sich daher höchstwahrscheinlich in naher Zukunft nicht ändern.Daher bevorzuge ich es, alle relevanten Teile auf einmal sichtbar zu haben, anstatt zu einer anderen Methode mit dem Namen checkMatrixAtRow(x) scrollen zu müssen.

Besonders bei komplexeren mathematischen Algorithmen fällt es mir ziemlich schwer, „gute“ Funktionsnamen zu finden – aber das ist wohl noch eine andere Frage

Answer 8

Ich denke, dass beschriftete Schleifen so ungewöhnlich sind, dass Sie die für Sie geeignete Beschriftungsmethode auswählen können – was Sie dort haben, macht Ihre Absichten mit den Fortsetzungen völlig klar.

---

Nachdem ich den Vorwurf erhoben habe, eine Umgestaltung der Schleifen in der ursprünglichen Frage vorzuschlagen, und nun den fraglichen Code gesehen habe, denke ich, dass Sie dort eine sehr gut lesbare Schleife haben.

Was ich mir vorgestellt hatte, war ein ganz anderer Teil des Codes – wenn ich mir das tatsächliche Beispiel anschaue, kann ich sehen, dass es viel sauberer ist, als ich gedacht hatte.

Ich entschuldige mich für das Missverständnis.

Answer 9

Geht das für dich?Ich habe die innere Schleife in eine Methode CheckedEntireMatrix extrahiert (Sie können sie besser benennen als ich) – Außerdem ist mein Java etwas eingerostet.aber ich denke, es bringt die Botschaft rüber

for( int idx = 0; idx < vectorLength; idx++) {
    if( conditionAtVectorPosition( v, idx ) 
    || !CheckedEntireMatrix(v)) continue;

    setValueInVector( v, idx );
}

private bool CheckedEntireMatrix(Vector v)
{
    for( rowIdx = 0; rowIdx < n; rowIdx++ ) {
        if( anotherConditionAtVector( v, rowIdx ) ) continue;
        if( conditionAtMatrixRowCol( m, rowIdx, idx ) ) return false;
    }   
    return true;
}

Answer 10

Gishu hat die richtige Idee:

for( int idx = 0; idx < vectorLength; idx++) {
    if (!conditionAtVectorPosition( v, idx ) 
        && checkedRow(v, idx))
         setValueInVector( v, idx );
}

private boolean checkedRow(Vector v, int idx) {
    for( rowIdx = 0; rowIdx < n; rowIdx++ ) {
        if( anotherConditionAtVector( v, rowIdx ) ) continue;
        if( conditionAtMatrixRowCol( m, rowIdx, idx ) ) return false;
    }  
    return true;
}

Answer 11

Ich bin mir nicht ganz sicher, ob ich die erste Fortsetzung verstehe.Ich würde Gishu kopieren und so etwas schreiben (entschuldigen Sie, wenn es Fehler gibt):

for( int idx = 0; idx < vectorLength; idx++) {
    if( !conditionAtVectorPosition( v, idx ) && CheckedEntireMatrix(v))
        setValueInVector( v, idx );
}

inline bool CheckedEntireMatrix(Vector v) {
    for(rowIdx = 0; rowIdx < n; rowIdx++)
        if ( !anotherConditionAtVector(v,rowIdx) && conditionAtMatrixRowCol(m,rowIdx,idx) ) 
            return false;
    return true;
}

Answer 12

@Sadie:

Sie sehen alle weniger lesbar aus als das Original, da mehr Code für den Mechanismus des Codes aufgewendet wird als für den Algorithmus selbst

Die Externalisierung der zweiten Schleife außerhalb des Algorithmus ist nicht unbedingt weniger lesbar.Wenn der Methodenname gut gewählt ist, kann er die Lesbarkeit verbessern.

Einige davon sind kaputt oder waren es schon, bevor sie bearbeitet wurden.Am verheerendsten ist die Tatsache, dass die Leute ziemlich intensiv darüber nachdenken müssen, wie sie den Code ohne Labels schreiben können, ohne dass etwas kaputt geht.

Ich bin anderer Meinung:Einige von ihnen sind fehlerhaft, weil es schwierig ist, das Verhalten des ursprünglichen Algorithmus herauszufinden.

Bei einigen kommt es zu Leistungseinbußen, wenn derselbe Test zweimal ausgeführt wird, was nicht immer trivial ist.Die Alternative dazu ist das Speichern und Weitergeben von Booleschen Werten, was hässlich wird.

Die Leistungseinbußen sind gering.Allerdings stimme ich zu, dass es keine gute Lösung ist, einen Test zweimal durchzuführen.

Den relevanten Teil des Codes in eine Methode umzugestalten, ist praktisch ein No-Op:Es ordnet die Anordnung des Codes in der Datei neu an, hat jedoch keinen Einfluss auf die Art und Weise, wie er ausgeführt wird.

Ich verstehe den Sinn nicht.Ja, es ändert nichts am Verhalten, wie ...Refactoring?

Sicherlich gibt es Fälle, in denen Etiketten falsch verwendet werden und umgestaltet werden sollten.Ich denke einfach nicht, dass es als eine unumstößliche Regel betrachtet werden sollte.

Ich bin vollkommen einverstanden.Aber wie Sie bereits betont haben, haben einige von uns Schwierigkeiten bei der Umgestaltung dieses Beispiels.Auch wenn das erste Beispiel lesbar ist, ist es schwer beizubehalten.