Le développeur insiste sur le fait que les déclarations ne doivent pas avoir des conditions négatives, mais doivent toujours avoir un bloc else

J'ai une connaissance, un développeur plus expérimenté que moi. Nous parlions de pratiques de programmation et son approche des déclarations «if» m'a surpris. Il insiste sur certaines pratiques concernant les déclarations que je trouve plutôt étranges.

Premièrement , une déclaration if devrait être suivie d'une déclaration else, qu'il y ait quelque chose à ajouter ou non. Ce qui conduit à un code ressemblant à ceci:

if(condition) 
{
    doStuff();
    return whatever;
}
else
{
}

Deuxièmement , il est préférable de tester les vraies valeurs plutôt que les fausses. Cela signifie qu'il est préférable de tester une variable 'doorClosed' au lieu d'une variable '! DoorOpened'

Son argument est que cela clarifie ce que fait le code.

Ce qui me trouble un peu, car la combinaison de ces deux règles peut l'amener à écrire ce type de code s'il veut faire quelque chose lorsque la condition n'est pas remplie.

if(condition)
{
}
else
{
    doStuff();
    return whatever;
}

Mon sentiment à ce sujet est qu’il est en effet très moche et / ou que l’amélioration de la qualité, s’il y en a une, est négligeable. Mais en tant que junior, je suis susceptible de douter de mon instinct.

Mes questions sont donc les suivantes: est-ce une pratique bonne / mauvaise / "peu importe"? Est-ce une pratique courante?

elseBloc explicite

La première règle ne fait que polluer le code et ne le rend pas plus lisible, ni moins sujet aux erreurs. Je suppose que l'objectif de votre collègue est d'être explicite en montrant que le développeur était parfaitement conscient du fait que la condition peut être évaluée à false. Bien que ce soit une bonne chose d'être explicite, une telle explicité ne devrait pas coûter trois lignes de code supplémentaires .

Je ne mentionne même pas le fait qu’une ifdéclaration n’est pas nécessairement suivie d’un elseou de rien: elle peut aussi être suivie d’un ou de plusieurs elifmots.

La présence de la returndéclaration aggrave les choses. Même si vous aviez du code à exécuter dans le elsebloc, il serait plus facile de le faire comme ceci:

if (something)
{
    doStuff();
    return whatever;
}

doOtherThings();
return somethingElse;

Cela fait que le code prenne deux lignes de moins et annule le elseblocage. Les clauses de garde sont toutes à ce sujet.

Notez cependant que la technique de votre collègue pourrait résoudre partiellement un très vilain schéma de blocs conditionnels empilés sans espaces:

if (something)
{
}
if (other)
{
}
else
{
}

Dans le code précédent, le manque de saut de ligne sain après le premier ifbloc rend très facile l’interprétation erronée du code. Cependant, alors que la règle de votre collègue rendrait plus difficile la mauvaise interprétation du code, une solution plus simple consisterait simplement à ajouter une nouvelle ligne.

Tester pour true, pas pourfalse

La deuxième règle pourrait avoir un sens, mais pas dans sa forme actuelle.

Il n'est pas faux de dire que le test d'une porte fermée est plus intuitif que celui d'une porte non ouverte . Les négations, et en particulier les négations imbriquées, sont généralement difficiles à comprendre:

if (!this.IsMaster || (!this.Ready && !this.CanWrite))

Pour résoudre ce problème, au lieu d’ajouter des blocs vides, créez des propriétés supplémentaires, le cas échéant, ou des variables locales .

La condition ci-dessus pourrait être rendue lisible assez facilement:

if (this.IsSlave || (this.Synchronizing && this.ReadOnly))

En ce qui concerne la première règle, il s’agit d’un exemple de saisie inutile. Non seulement cela prend plus de temps à taper, cela causera une énorme confusion à quiconque lira le code. Si le code n'est pas nécessaire, ne l'écrivez pas. Cela s’étendrait même à ne pas avoir un cas rempli elsedans votre cas lorsque le code revient du ifbloc:

if(condition) 
{
    doStuff();
    return whatever;
}

doSomethingElse(); // no else needed
return somethingelse;

En ce qui concerne le deuxième point, il convient d’éviter les noms booléens contenant un négatif:

bool doorNotOpen = false; // a double negative is hard to reason
bool doorClosed = false; // this is much clearer

Toutefois, comme vous l'avez souligné, le fait d'étendre cette procédure à l'absence de contrôle négatif d'un test négatif conduit à une saisie plus inutile. Ce qui suit est bien plus clair que d'avoir un ifbloc vide :

if(!condition)
{
    doStuff();
    return whatever;
}

1. Un argument en faveur des elsedéclarations vides .

J'utilise souvent (et plaide pour) quelque chose qui ressemble à cette première construction, une autre vide. Cela indique aux lecteurs du code (outils d'analyse humains et automatisés) que le programmeur a réfléchi à la situation. Les elsedéclarations manquantes qui auraient dû être présentes ont tué des personnes, fait tomber des véhicules et coûté des millions de dollars. MISRA-C, par exemple, impose au moins un commentaire indiquant que la dernière finale manquante est intentionnelle dans une if (condition_1) {do_this;} else if (condition_2) {do_that;} ... else if (condition_n) {do_something_else;}séquence. D'autres normes de haute fiabilité vont encore plus loin: à quelques exceptions près, les autres déclarations manquantes sont interdites.

Une exception est un simple commentaire, quelque chose du genre /* Else not required */. Cela signale la même intention que les trois lignes vides. Une autre exception où ce vide vide n'est pas nécessaire est celle où cela est flagrant pour les lecteurs du code et pour les outils d'analyse automatisés que ce vide vide est superflu. Par exemple, de if (condition) { do_stuff; return; }même, un caractère vide n'est pas nécessaire dans le cas de throw somethingou goto some_label¹ au lieu du return.

2. Un argument pour préférer if (condition)plus if (!condition).

Ceci est un élément de facteurs humains. La logique booléenne complexe attire beaucoup de monde. Même un programmeur expérimenté devra réfléchir if (!(complex || (boolean && condition))) do_that; else do_this;. Au minimum, réécrivez cela en tant que if (complex || (boolean && condition)) do_this; else do_that;.

3. Cela ne signifie pas qu'il faille préférer les thendéclarations vides .

La deuxième section dit "préfère" plutôt que "tu vas". C'est une ligne directrice plutôt qu'une règle. La raison pour laquelle cette directive privilégie les ifconditions positives est que le code doit être clair et évident. Une clause alors vide (par exemple, if (condition) ; else do_something;) viole cela. C'est une programmation obscurcie, ce qui amène même les programmeurs les plus aguerris à sauvegarder et à relire la ifsituation sous sa forme annulée. Donc, écrivez-le sous la forme refusée en premier lieu et omettez la déclaration else (ou ayez un caractère vide ou un commentaire à cet effet s'il est mandaté pour le faire).

¹ J'ai écrit qu'alors les clauses qui se terminent par return, throwou goton'exigent pas de vide. Il est évident que la clause else n'est pas nécessaire. Mais qu'en est-il goto? En passant, les règles de programmation critiques pour la sécurité interdisent parfois les retours anticipés, et interdisent presque toujours les exceptions de lancement. Ils permettent cependant gotosous une forme restreinte (par exemple goto cleanup1;). Cette utilisation restreinte de gotoest la pratique préférée dans certains endroits. Le noyau Linux, par exemple, est plein à craquer de telles gotodéclarations.

J'utilise une branche else vide (et parfois une branche if vide) dans de très rares cas: lorsqu'il est évident que les parties if et else doivent être traitées d'une manière ou d'une autre, mais que, pour une raison quelconque, le cas peut être traité par Ne rien faire. Et par conséquent, toute personne lisant le code avec l’action else nécessaire suspecterait immédiatement qu’il manquait quelque chose et perdrait son temps.

if (condition) {
    // No action needed because ...
} else {
    do_else_action()
}

if (condition) {
    do_if_action()
} else {
    // No action needed because ...
}

Mais non:

if (condition) {
    do_if_action()
} else {
    // I was told that an if always should have an else ...
}

Toutes choses égales par ailleurs, préférez la brièveté.

Ce que vous n'écrivez pas, personne ne doit lire et comprendre.

Bien qu'explicite puisse être utile, ce n'est le cas que s'il est évident, sans trop de verbosité, que ce que vous avez écrit est vraiment ce que vous vouliez écrire.

Donc, évitez les branches vides, elles sont non seulement inutiles, mais aussi rares et créent donc la confusion.

De même, évitez d'écrire une autre branche si vous quittez directement la branche if.

Une application utile de la clarté consisterait à mettre un commentaire chaque fois que vous tombez dans le casse // FALLTHRU, et à utiliser un commentaire ou un bloc vide dans lequel vous avez besoin d'une instruction vide for(a;b;c) /**/;.

À ma connaissance, il n’existe pas de règle absolue concernant les conditions positives ou négatives d’un énoncé IF. Personnellement, je préfère coder pour un cas positif que pour un cas négatif, le cas échéant. Je ne le ferai certainement pas, cependant, si cela me conduit à créer un bloc SI vide, suivi d'un autre élément logique. Si une telle situation se produisait, cela prendrait environ 3 secondes pour le refactoriser à nouveau pour rechercher un cas positif de toute façon.

Ce que je n'aime pas vraiment dans vos exemples, c’est l’espace vertical totalement inutile occupé par le ELSE vierge. Il n'y a tout simplement aucune raison de le faire. Cela n'ajoute rien à la logique, cela n'aide pas à documenter ce que fait le code, et cela n'augmente pas la lisibilité. En fait, je dirais que l’espace vertical ajouté pourrait éventuellement diminuer la lisibilité.

elseBloc explicite

Je ne suis pas d’accord avec cette affirmation en tant que déclaration générale couvrant toutes les ifdéclarations, mais il arrive que l’ajout d’un elsebloc par habitude soit une bonne chose.

Une ifdéclaration, à mon avis, recouvre en réalité deux fonctions distinctes.

Si nous sommes censés faire quelque chose, faites-le ici.

Ce genre de choses n'a évidemment pas besoin d'une elsepartie.

    if (customer.hasCataracts()) {
        appointmentSuggestions.add(new CataractAppointment(customer));
    }
    if (customer.isDiabetic()) {
        customer.assignNurse(DiabeticNurses.pickBestFor(customer));
    }

et dans certains cas insister pour ajouter un elsepourrait induire en erreur.

    if (k > n) {
        return BigInteger.ZERO;
    }
    if (k <= 0 || k == n) {
        return BigInteger.ONE;
    }

n'est pas la même chose que

    if (k > n) {
        return BigInteger.ZERO;
    } else {
        if (k <= 0 || k == n) {
            return BigInteger.ONE;
        }
    }

même si c'est fonctionnellement le même. Écrire le premier ifavec un vide elsepeut vous mener au deuxième résultat qui est inutilement laid.

Si nous recherchons un état spécifique, il est souvent judicieux d’ajouter un vide elseafin de vous rappeler de couvrir cette éventualité.

        // Count wins/losses.
        if (doors[firstChoice] == Prize.Car) {
            // We would have won without switching!
            winWhenNotSwitched += 1;
        } else {
            // We win if we switched to the car!
            if (doors[secondChoice] == Prize.Car) {
                // We picked right!
                winWhenSwitched += 1;
            } else {
                // Bad choice.
                lost += 1;
            }
        }

N'oubliez pas que ces règles s'appliquent uniquement lorsque vous écrivez un nouveau code . IMHO Les elseclauses vides doivent être supprimées avant l'archivage.

Tester pour true, pas pourfalse

Là encore, c’est un bon conseil au niveau général, mais dans de nombreux cas, cela rend le code inutilement complexe et moins lisible.

Même si le code comme

    if(!customer.canBuyAlcohol()) {
        // ...
    }

est choquant pour le lecteur, mais en le rendant

    if(customer.canBuyAlcohol()) {
        // Do nothing.
    } else {
        // ...
    }

est au moins aussi mauvais, sinon pire.

J'ai codé dans BCPL il y a de nombreuses années et dans cette langue, il y a une IFclause et une UNLESSclause afin que vous puissiez coder beaucoup plus facilement comme suit:

    unless(customer.canBuyAlcohol()) {
        // ...
    }

ce qui est nettement meilleur, mais toujours pas parfait.

Mon processus personnel

Généralement, lorsque j'écris un nouveau code, j'ajoute souvent un elsebloc vide à une ifdéclaration simplement pour me rappeler que je n'ai pas encore couvert cette éventualité. Cela m'aide à éviter le DFSpiège et à s'assurer que lorsque je relis le code, je constate qu'il reste encore beaucoup à faire. Cependant, j'ajoute généralement un TODOcommentaire pour garder une trace.

  if (returnVal == JFileChooser.APPROVE_OPTION) {
    handleFileChosen();
  } else {
    // TODO: Handle case where they pressed Cancel.
  }

Je trouve que généralement j'utilise elserarement dans mon code car il peut souvent indiquer une odeur de code.

Pour le premier point, j’ai utilisé un langage qui forçait les déclarations IF à être utilisé de cette façon (dans Opal, le langage situé derrière un grattoir d’écran principal pour placer une interface graphique sur les systèmes mainframe) et avec une seule ligne pour le SI. et les autres. Ce n'était pas une expérience agréable!

Je m'attendrais à ce que tout compilateur optimise ces clauses ELSE supplémentaires. Mais pour le code live, cela n’ajoute rien (en développement, cela peut être un marqueur utile pour le code suivant).

Une fois que j'utilise quelque chose comme ces clauses supplémentaires, c'est lors de l'utilisation du traitement de type CASE / WHEN. J'ajoute toujours une clause par défaut même si elle est vide. C’est une habitude à long terme de la part de langages qui vont se tromper si une telle clause n’est pas utilisée, et oblige à se demander si les choses doivent vraiment passer à travers.

Il y a longtemps, la pratique des ordinateurs centraux (par exemple, PL / 1 et COBOL) supposait que les contrôles négatifs étaient moins efficaces. Cela pourrait expliquer le deuxième point, bien que de nos jours, il existe des économies d’efficacité considérablement plus importantes qui sont ignorées sous forme de micro optimisations.

La logique négative a tendance à être moins lisible, mais pas tellement sur une déclaration IF aussi simple.

Je souscris à la plupart des réponses selon lesquelles les elseblocs vides sont pratiquement toujours un gaspillage d’encre électronique. N'ajoutez pas ceci à moins que vous n'ayez une très bonne raison de le faire. Dans ce cas, le bloc vide ne devrait pas être vide du tout, il devrait contenir un commentaire expliquant pourquoi il est là.

Cependant, le problème de l’évitement des négatifs mérite plus d’attention: en règle générale, chaque fois que vous devez utiliser une valeur booléenne, vous avez besoin de blocs de code pour pouvoir fonctionner lorsqu’il est défini, et d’autres pour fonctionner s’ils ne le sont pas. En tant que tel, si vous appliquez une règle de non-négatif, vous appliquez soit des if() {} else {...}déclarations ayant (avec un ifbloc vide !), Soit vous créez un deuxième booléen pour chaque booléen contenant sa valeur annulée. Les deux options sont mauvaises, car elles déroutent vos lecteurs.

Une politique utile est la suivante: n'utilisez jamais un formulaire avec négation dans le nom d'un booléen et exprimez la négation en tant que simple !. Une déclaration comme if(!doorLocked)est parfaitement claire, une déclaration comme des if(!doorUnlocked)nœuds cerveaux. Le dernier type d’expression est ce que vous devez éviter à tout prix, pas la présence d’un seul !dans une if()condition.

Je dirais que c'est définitivement une mauvaise pratique. Ajouter d’autres instructions va ajouter à votre code toute une série de lignes inutiles qui ne font rien et le rendent encore plus difficile à lire.

Il y a un autre motif qui n'a pas encore été mentionné concernant le traitement du deuxième cas qui a un bloc if vide. Une façon de régler ce problème serait de revenir dans le bloc if. Comme ça:

void foo()
{
    if (condition) return;

    doStuff();
    ...
}

C'est un modèle courant pour vérifier les conditions d'erreur. Le cas affirmatif est toujours utilisé et son contenu n'est plus vide, laissant les futurs programmeurs se demander si un non-op était intentionnel ou non. Cela peut également améliorer la lisibilité, car il se peut que vous deviez créer une nouvelle fonction (divisant ainsi de grandes fonctions en fonctions individuelles plus petites).

Il y a un point en considérant l'argument "toujours avoir une clause else" que je n'ai vu dans aucune autre réponse: cela peut avoir un sens dans un style de programmation fonctionnel. Sorte de.

Dans un style de programmation fonctionnel, vous manipulez des expressions plutôt que des instructions. Ainsi, chaque bloc de code a une valeur de retour, y compris une if-then-elseexpression. Cela empêcherait toutefois un elsebloc vide . Laissez-moi vous donner un exemple:

var even = if (n % 2 == 0) {
  return "even";
} else {
  return "odd";
}

Maintenant, dans les langages avec un style C ou une syntaxe inspirée du style C (comme Java, C # et JavaScript, pour n'en nommer que quelques-uns), cela a l'air bizarre. Cependant, il semble beaucoup plus familier lorsqu'il est écrit en tant que tel:

var even = (n % 2 == 0) ? "even" : "odd";

Si vous laissez la elsebranche vide ici, une valeur ne sera pas définie - dans la plupart des cas, ce n'est pas ce que nous voulons être un cas valide lors de la programmation de fonctionnalités. Même avec le laisser complètement. Cependant, lorsque vous programmez de manière itérative, je vous donne très peu de raisons de toujours avoir un elsebloc.

... une déclaration if devrait être suivie d'une déclaration else, qu'il y ait quelque chose à ajouter ou non.

Je suis en désaccord if (a) { } else { b(); }devrait être ré-écrit comme if (!a) { b(); }et if (a) { b(); } else { }devrait être ré-écrit comme if (a) { b(); }.

Toutefois, il convient de souligner que j'ai rarement une branche vide. C'est parce que normalement je me connecte que je suis entré dans la branche autrement vide. De cette façon, je peux développer uniquement des messages de journalisation. J'utilise rarement un débogueur. Dans les environnements de production, vous ne recevez pas de débogueur; il est agréable de pouvoir résoudre les problèmes de production avec les mêmes outils que ceux que vous utilisez pour développer.

Deuxièmement, il est préférable de tester les vraies valeurs plutôt que les fausses. Cela signifie qu'il est préférable de tester une variable 'doorClosed' au lieu d'une variable '! DoorOpened'

J'ai des sentiments mitigés à ce sujet. Un inconvénient d'avoir doorClosedet doorOpenedest - il peut doubler le nombre de mots / termes que vous devez être au courant. Avec le temps, un autre inconvénient est la signification de doorClosedet doorOpenedpeut changer (d'autres développeurs arrivant après vous) et vous pouvez vous retrouver avec deux propriétés qui ne sont plus des négations précises l'une de l'autre. Au lieu d'éviter les négations, j'apprécie d'adapter la langue du code (noms de classes, noms de variables, etc.) au vocabulaire des utilisateurs professionnels et aux exigences qui me sont données. Je ne voudrais pas inventer un nouveau terme pour éviter un!si ce terme n'a de signification pour un développeur que les utilisateurs professionnels ne comprendront pas. Je souhaite que les développeurs parlent le même langage que les utilisateurs et les personnes qui rédigent les exigences. Maintenant, si de nouveaux termes simplifient le modèle, c'est important, mais vous devez le gérer avant la finalisation des exigences, pas après. Le développement devrait gérer ce problème avant de commencer à coder.

Je suis enclin à douter de mon instinct.

C'est bien de continuer à se questionner.

Est-ce une bonne / mauvaise / pratique "n'a pas d'importance"?

Dans une certaine mesure, cela n'a pas d'importance. Obtenez votre code révisé et adapter à votre équipe. C'est généralement la bonne chose à faire. Si tous les membres de votre équipe souhaitent coder d'une certaine manière, il est probablement préférable de le faire de cette façon (changer de personne - vous-même - nécessite moins de points de récit que de changer de groupe de personnes).

Est-ce une pratique courante?

Je ne me souviens pas avoir jamais vu une branche vide. Je vois des gens ajouter des propriétés pour éviter les négations, cependant.

Je vais seulement aborder la deuxième partie de la question et cela vient de mon point de vue de travailler dans des systèmes industriels et de manipuler des appareils dans le monde réel.

Cependant, il s’agit en quelque sorte d’un commentaire étendu plutôt que d’une réponse.

Quand il est déclaré

Deuxièmement, il est préférable de tester les vraies valeurs plutôt que les fausses. Cela signifie qu'il est préférable de tester une variable 'doorClosed' au lieu d'une variable '! DoorOpened'

Son argument est que cela clarifie ce que fait le code.

De mon point de vue, on suppose ici que l'état de la porte est un état binaire alors qu'en fait il s'agit au moins d'un état ternaire:

1. La porte est ouverte.
2. La porte n'est ni complètement ouverte ni complètement fermée.
3. La porte est fermée.

Ainsi, selon l’emplacement d’un capteur numérique binaire, vous ne pouvez conjecturer qu’un des deux concepts suivants:

1. Si le capteur est sur le côté ouvert de la porte: la porte est ouverte ou non ouverte
2. Si le capteur est sur le côté fermé de la porte: La porte est fermée ou non fermée.

Et vous ne pouvez pas échanger ces concepts en utilisant une négation binaire. Ainsi, doorClosedet ne !doorOpenedsont probablement pas synonymes, et toute tentative de prétendre qu’elles sont synonymes est une pensée erronée qui suppose une meilleure connaissance de l’état du système qu’elle n’existe réellement.

Pour revenir à votre question, j'appuierais un verbiage qui correspond à l'origine de l'information représentée par la variable. Ainsi, si les informations proviennent du côté fermé de la porte, allez-y avec, doorClosedetc. Cela peut impliquer d'utiliser l'une doorClosedou l' autre ou !doorClosedselon les besoins dans diverses déclarations, selon les besoins, ce qui risque de créer une confusion avec l'utilisation de la négation. Mais ce qu’elle ne fait pas, c’est propager implicitement des hypothèses sur l’état du système.

À des fins de discussion pour le travail que je fais, la quantité d'informations dont je dispose sur l'état du système dépend des fonctionnalités requises par le système dans son ensemble.

Parfois, je n'ai besoin que de savoir si la porte est fermée ou non. Dans ce cas, un seul capteur binaire suffira. Mais à d'autres moments, j'ai besoin de savoir que la porte est ouverte, fermée ou en transition. Dans ce cas, il y aurait soit deux capteurs binaires (à chaque extrémité du mouvement de la porte - la vérification des erreurs s'opérant simultanément contre l'ouverture et la fermeture de la porte), soit un capteur analogique mesurant le degré d'ouverture de la porte.

Un exemple de la première serait la porte sur un four à micro-ondes. Vous activez le fonctionnement du four lorsque la porte est fermée ou non. Vous ne vous souciez pas de la façon dont la porte est ouverte.

Un exemple du second serait un simple actionneur entraîné par moteur. Vous empêchez d'avancer le moteur lorsque l'actionneur est complètement sorti. Et vous empêchez le moteur d’être inversé lorsque l’actionneur est complètement enfoncé.

Fondamentalement, le nombre et le type de capteurs se résument à une analyse de coût des capteurs par rapport à une analyse des besoins de ce qui est nécessaire pour obtenir la fonctionnalité requise.

Les règles de style concrètes sont toujours mauvaises. Les directives sont bonnes, mais à la fin, il est souvent possible de clarifier des choses en faisant quelque chose qui ne les suit pas tout à fait.

Cela dit, il y a beaucoup de haine pour le vide vide "ça gaspille les lignes", "le dactylographie supplémentaire", ce qui est tout simplement mauvais. Vous pouvez argumenter en faveur du déplacement des crochets sur la même ligne si vous avez vraiment besoin d'espace vertical, mais si cela pose un problème, vous ne devriez de toute façon pas placer votre {sur une ligne séparée.

Comme mentionné précédemment, le bloc else est très utile pour montrer que vous voulez explicitement que rien ne se passe dans l'autre cas. Après avoir effectué beaucoup de programmation fonctionnelle (là où il est nécessaire d’autre chose), j’ai appris que vous devriez toujours tenir compte de l’autre lors de la rédaction du if, bien que @OldCurmudgeon mentionne qu’il existe vraiment deux cas d’utilisation différents. On devrait avoir un autre, on ne devrait pas. Malheureusement, ce n'est pas quelque chose que vous pouvez toujours dire en un coup d'œil, encore moins avec un linter, d'où le dogme "toujours mis un autre bloc".

En ce qui concerne les "non-négatifs", encore une fois, les règles absolues sont mauvaises. Avoir un vide si peut être étrange, surtout si c'est le type de si cela n'a pas besoin d'autre chose, alors écrivez tout ça plutôt qu'un! ou un == faux est mauvais. Cela dit, il y a beaucoup de cas où le négatif a du sens. Un exemple courant consisterait à mettre en cache une valeur:

static var cached = null

func getCached() {
    if !cached {
        cached = (some calculation, etc)
    }

    return cached
}

si la logique réelle (mentale / anglaise) implique un négatif, il devrait en être de même de l'instruction if.