Einführung zusätzlicher lokaler Variablen als Kommentarersetzung

Ist es sinnvoll, zusätzliche, technisch überflüssige lokale Variablen zu verwenden, um zu beschreiben, was passiert?

Beispielsweise:

bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */);

if(easyUnderstandableIsTrue)
{
    // ...
}

Wenn es um technischen Aufwand geht, erwarte ich, dass der Compiler diese zusätzliche Zeile optimiert. Aber wird es als unnötiger Code-Schwall angesehen? In meinen Augen verringert sich das Risiko abgestandener Kommentare.

Was kostet eine zusätzliche Variable? In den meisten Sprachen keine, sowohl in kompilierten als auch in interpretierten Sprachen.

Was ist der Vorteil davon?

• Ähnlich wie beim Extrahieren des kryptischen booleschen Ausdrucks in eine separate Methode verringern Sie das Risiko von Code-Duplikaten , jedoch etwas weniger als bei einer separaten Methode. Wenn der bedingte Ausdruck innerhalb der Methode selbst wiederverwendet wird, können Sie die Variable wiederverwenden. Wenn der Ausdruck in einer anderen Methode angezeigt wird, werden Sie nicht.

  Beachten Sie, dass ein solches Refactoring langfristig riskant sein kann, es sei denn, Ihre Programmiersprache erlaubt Ihnen, unveränderliche lokale Variablen zu verwenden, oder Sie haben die Möglichkeit, stilistisch zu erzwingen, dass keine der Variablen neu zugewiesen wird. Wenn der Wert der Variablen geändert wird, kann es sehr schwierig sein, über den Code nachzudenken.

• Sie verringern das Risiko, dass die Dokumentation nicht mehr mit dem Code synchronisiert wird . Entwickler neigen dazu, die Namen von Variablen und Methoden einfacher zu aktualisieren als die Kommentare.¹ Daher ist es nicht ungewöhnlich, dass Code wie folgt angezeigt wird:

    // Find if the user is an actual author in order to allow her to edit the message.
    if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))

Der Ausdruck begann wahrscheinlich mit if (message.author == currentUser)und wurde dann entwickelt, um den Fall von gesperrten Nachrichten und Administratoren zu behandeln, die keine Autoren sein müssen und sich nicht für gesperrte Inhalte interessieren. Der Kommentar spiegelt jedoch keine dieser Änderungen wider.

Beide Vorteile sind nicht besonders wichtig, aber angesichts der geringen Kosten für zusätzliche Variablen können Sie sie in Betracht ziehen.

Beachten Sie Folgendes, wenn Ihr boolescher Ausdruck zu komplex wird: ²

• Extrahieren Sie es in eine separate Methode und:
• Zerlegen Sie es in mehrere einfache boolesche Ausdrücke.

Das obige Beispiel wird:

class Message
{
    ...
    public boolean canBeEditedBy(User user)
    {
        ...
        if (user.isAdministrator) {
            return true;
        }

        return this.author == user && !this.locked;
    }
}

...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
    ...
}

^{¹ Quelle: meine eigene Beobachtung meiner Kollegen, die hauptsächlich Unternehmenssoftware entwickeln; YMMV. Eine echte Forschung kann unterschiedliche Ergebnisse zeigen. Persönlich denke ich, wenn Entwickler Code lesen, konzentrieren sie sich auf den Code , und Kommentare sind Dokumentation, nicht Code. Daher lesen sie normalerweise keine Kommentare, sodass es schwierig ist, von ihnen zu erwarten, dass sie sie aktualisieren.}

^{² Die zu komplexe Schwelle wird mit einer einfachen Formel definiert: Wenn die Hälfte der Entwickler, die Ihren Code überprüfen, die Absicht zum Ausdruck bringt, Sie umzubringen, ist die Schwelle erreicht. Der obige boolesche Ausdruck ist einfach genug, um ein Refactoring zu erfordern. Vier Teile in einer Reihe if ((a && b) || (c && d))würden es jedoch möglicherweise überarbeitbar machen. Beachten Sie, dass, wenn der Ausdruck flach ist, die Anzahl der Teile größtenteils irrelevant ist: Ist if (a || b || c || d || ... || z)ausreichend lesbar.}