Pourquoi voit-on souvent «null! = Variable» au lieu de «variable! = Null» en C #?

En c #, y a-t-il une différence de vitesse d'exécution pour l'ordre dans lequel vous énoncez la condition?

if (null != variable) ...
if (variable != null) ...

Depuis récemment, j'ai vu le premier assez souvent, et il a retenu mon attention puisque j'étais habitué au second.

S'il n'y a pas de différence, quel est l'avantage du premier?

C'est un retard de C. En C, si vous utilisez un mauvais compilateur ou si vous n'avez pas d'avertissements suffisamment élevés, cela se compilera sans aucun avertissement (et c'est en effet du code légal):

// Probably wrong
if (x = 5)

quand tu voulais probablement dire

if (x == 5)

Vous pouvez contourner ce problème en C en faisant:

if (5 == x)

Une faute de frappe ici entraînera un code invalide.

Maintenant, en C #, tout est piffle. À moins que vous ne compariez deux valeurs booléennes (ce qui est rare, IME), vous pouvez écrire le code le plus lisible, car une instruction "if" nécessite une expression booléenne pour commencer, et le type de " x=5" est Int32, non Boolean.

Je suggère que si vous voyez cela dans le code de vos collègues, vous les éduquez aux voies des langues modernes et suggérez qu'ils écrivent la forme la plus naturelle à l'avenir.

Il y a une bonne raison d'utiliser d'abord null: if(null == myDuck)

Si votre class Duckremplace l' ==opérateur, alors if(myDuck == null)peut entrer dans une boucle infinie.

Utiliser nullfirst utilise un comparateur d'égalité par défaut et fait réellement ce que vous vouliez.

(J'entends que vous vous habituez finalement à lire du code écrit de cette façon - je n'ai tout simplement pas encore vécu cette transformation)

Voici un exemple:

public class myDuck
{
    public int quacks;
    static override bool operator ==(myDuck a, myDuck b)
    {
        // these will overflow the stack - because the a==null reenters this function from the top again
        if (a == null && b == null)
            return true;
        if (a == null || b == null)
            return false;

        // these wont loop
        if (null == a && null == b)
            return true;
        if (null == a || null == b)
            return false;
        return a.quacks == b.quacks; // this goes to the integer comparison
    }
}

Comme tout le monde l'a déjà noté, cela vient plus ou moins du langage C où vous pourriez obtenir un faux code si vous oubliez accidentellement le deuxième signe égal. Mais il y a une autre raison qui correspond également à C #: la lisibilité.

Prenons juste cet exemple simple:

if(someVariableThatShouldBeChecked != null
   && anotherOne != null
   && justAnotherCheckThatIsNeededForTestingNullity != null
   && allTheseChecksAreReallyBoring != null
   && thereSeemsToBeADesignFlawIfSoManyChecksAreNeeded != null)
{
    // ToDo: Everything is checked, do something...
}

Si vous permutez simplement tous les mots nuls au début, vous pouvez repérer beaucoup plus facilement toutes les vérifications:

if(null != someVariableThatShouldBeChecked
   && null != anotherOne
   && null != justAnotherCheckThatIsNeededForTestingNullity
   && null != allTheseChecksAreReallyBoring
   && null != thereSeemsToBeADesignFlawIfSoManyChecksAreNeeded)
{
    // ToDo: Everything is checked, do something...
}

Donc, cet exemple est peut-être un mauvais exemple (reportez-vous aux directives de codage), mais pensez simplement à faire défiler rapidement un fichier de code complet. En voyant simplement le motif

if(null ...

vous savez immédiatement ce qui va suivre.

Si c'était l'inverse, vous devez toujours scanner jusqu'à la fin de la ligne pour voir le contrôle de nullité, vous laissant simplement trébucher pendant une seconde pour savoir quel type de contrôle est effectué. Alors peut-être que la coloration syntaxique peut vous aider, mais vous êtes toujours plus lent lorsque ces mots-clés sont à la fin de la ligne au lieu du début.

Je suppose que c'est un programmeur C qui a changé de langue.

En C, vous pouvez écrire ce qui suit:

int i = 0;
if (i = 1)
{
    ...
}

Notez l'utilisation d'un seul signe égal ici, ce qui signifie que le code attribuera 1 à la variable i, puis retournera 1 (une affectation est une expression) et utilisera 1 dans l'instruction if, qui sera traitée comme vraie. En d'autres termes, ce qui précède est un bogue.

En C # cependant, ce n'est pas possible. Il n'y a en effet aucune différence entre les deux.

Autrefois, les gens oubliaient le «!» (ou le supplément '=' pour l'égalité, qui est plus difficile à repérer) et faites une affectation au lieu d'une comparaison. mettre le null devant élimine la possibilité du bogue, puisque null n'est pas une valeur l (IE il ne peut pas être assigné).

La plupart des compilateurs modernes donnent un avertissement lorsque vous effectuez une affectation dans un conditionnel de nos jours, et C # donne en fait une erreur. La plupart des gens s'en tiennent au schéma var == null car il est plus facile à lire pour certaines personnes.

Je ne vois aucun avantage à suivre cette convention. En C, où les types booléens n'existent pas, il est utile d'écrire

if( 5 == variable)

plutôt que

if (variable == 5)

car si vous oubliez l'un des signes égaux, vous vous retrouvez avec

if (variable = 5)

qui attribue 5 à la variable et toujours évalué à vrai. Mais en Java, un booléen est un booléen. Et avec! =, Il n'y a aucune raison du tout.

Un bon conseil, cependant, est d'écrire

if (CONSTANT.equals(myString))

plutôt que

if (myString.equals(CONSTANT))

car cela permet d'éviter les NullPointerExceptions.

Mon conseil serait de demander une justification de la règle. S'il n'y en a pas, pourquoi le suivre? Cela n'aide pas la lisibilité

Pour moi, c'est toujours le style que tu préfères

@Shy - Encore une fois, si vous confondez les opérateurs, vous devriez vouloir obtenir une erreur de compilation ou vous exécuterez du code avec un bogue - un bogue qui reviendra et vous mordra plus tard car il a produit un comportement inattendu

Comme beaucoup l'ont souligné, c'est principalement dans l'ancien code C qu'il a été utilisé pour identifier une erreur de compilation, car le compilateur l'a accepté comme légal

Les nouveaux langages de programmation comme java, go sont suffisamment intelligents pour capturer de telles erreurs de compilation

Il ne faut pas utiliser "null! = Variable" comme des conditions dans le code car il est très illisible

Une dernière chose ... Si vous comparez une variable à une constante (entier ou chaîne par exemple), mettre la constante à gauche est une bonne pratique car vous ne rencontrerez jamais NullPointerExceptions:

int i;
if(i==1){        // Exception raised: i is not initialized. (C/C++)
  doThis();
}

tandis que

int i;
if(1==i){        // OK, but the condition is not met.
  doThis();
}

Maintenant, puisque par défaut C # instancie toutes les variables, vous ne devriez pas avoir ce problème dans ce langage.