Introduction de variables locales supplémentaires comme remplacement de commentaire

Est-il judicieux d'utiliser des variables locales supplémentaires, techniquement superflues, pour décrire ce qui se passe?

Par exemple:

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

if(easyUnderstandableIsTrue)
{
    // ...
}

En ce qui concerne les frais généraux techniques, je m'attends à ce que le compilateur optimise cette ligne supplémentaire. Mais est-il considéré comme une surcharge de code inutile? À mes yeux, cela réduit le risque de commentaires périmés.

Quel est le coût d'avoir une variable supplémentaire? Dans la plupart des langues, aucune, à la fois dans les langues compilées et interprétées.

Quel est l'avantage de cela?

• De manière similaire à l'extraction de l'expression booléenne cryptique vers une méthode distincte, vous réduisez le risque de code dupliqué , mais légèrement moins que dans le cas d'une méthode distincte. Si l'expression conditionnelle est réutilisée à l'intérieur de la méthode elle-même, vous pourrez réutiliser la variable; si l'expression apparaît dans une méthode différente, vous ne le ferez pas.

  Notez qu'à moins que votre langage de programmation ne vous permette d'avoir des variables locales immuables ou que vous ayez un moyen d'imposer, par style, qu'aucune des variables n'est réaffectée, un tel refactoring pourrait être risqué à long terme. Si la valeur de la variable est modifiée, il pourrait être très difficile de raisonner sur le code.

• Vous réduisez le risque que la documentation ne soit plus synchronisée avec le code . Les développeurs ont tendance à mettre à jour les noms des variables et des méthodes plus facilement que les commentaires.¹ Ainsi, il n'est pas rare de voir du code tel que:

    // 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))

L'expression a probablement commencé par if (message.author == currentUser), puis a évolué pour gérer le cas des messages verrouillés et des administrateurs qui n'ont pas besoin d'être des auteurs et ne se soucient pas des choses verrouillées; cependant, le commentaire n'a reflété aucun de ces changements.

Les deux avantages ne sont pas particulièrement importants, mais étant donné le faible coût des variables supplémentaires, vous pouvez en effet envisager de les utiliser.

Notez que si votre expression booléenne devient trop complexe: ²

• Extrayez-le dans une méthode distincte et:
• Refactorisez-le en plusieurs expressions booléennes simples.

L'exemple ci-dessus devient:

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!
{
    ...
}

^{¹ Source: ma propre observation de mes pairs développant principalement des logiciels d'entreprise; YMMV. Une vraie recherche peut montrer des résultats différents. Personnellement, je suppose que lorsque les développeurs lisent du code, ils se concentrent sur le code et les commentaires sont de la documentation, pas du code; par conséquent, ils ne lisent généralement pas les commentaires, il serait donc difficile de s'attendre à ce qu'ils les mettent à jour.}

^{² Le seuil trop complexe est défini par une formule simple: si la moitié des développeurs qui examinent votre code expriment l'intention de vous assassiner, le seuil est atteint. L'expression booléenne ci-dessus est suffisamment simple pour nécessiter une refactorisation; cependant, quatre parties consécutives if ((a && b) || (c && d))le rendraient potentiellement refactorisable. Notez que si l'expression est plate, le nombre de parties n'est généralement pas pertinent: if (a || b || c || d || ... || z)est suffisamment lisible.}