Pourquoi on souvent voir « null ! = la variable » au lieu de « variable ! = null » en c# ?

Question

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

Depuis peu, j’ai vu la première assez souvent, et il a attiré mon attention puisque j’étais habitué à la seconde.

S’il n’y a pas de différence, quel est l’avantage de la première ?

Answer 1

C'est un hold-dessus de C. C, si vous utilisez un mauvais compilateur ou qui n'ont pas les avertissements tourné assez haut, cela permettra de compiler avec aucun avertissement préalable (et est en effet juridique de code):

// Probably wrong
if (x = 5)

en fait, quand vous signifiait probablement

if (x == 5)

Vous pouvez contourner ce problème en C par:

if (5 == x)

Une faute de frappe ici vont dans le code non valide.

Maintenant, en C# c'est tout piffle. Sauf si vous êtes de la comparaison de deux valeurs Booléennes (ce qui est rare, IME), vous pouvez écrire le code plus lisible, comme une instruction "if" exige une expression Booléenne pour commencer, et le type de "x=5" est - Int32, pas Boolean.

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

Answer 2

Il y a une bonne raison pour utiliser la valeur null première: if(null == myDuck)

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

À l'aide de null première utilise une valeur par défaut de l'égalité de comparaison et ne fait que vous avez été l'intention.

(J'entends que vous vous habituez à la lecture de code écrit en fin de compte je n'en ai pas connu cette transformation encore).

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
    }
}

Answer 3

Comme tout le monde l'a déjà noté, il s'agit plus ou moins du langage C où vous pourriez obtenir de faux code si vous avez accidentellement oubliez pas le deuxième signe égal. Mais il est une autre raison qui correspond également à la C#: Lisibilité.

Il suffit de prendre cet exemple simple:

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

Si vous souhaitez simplement échanger toutes les nuls mots pour le début, vous pouvez beaucoup plus facile de repérer tous les contrôles:

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 vous de défilement rapide sur un code complet du fichier. En la voyant simplement le modèle

if(null ...

vous savez tout de suite ce qui s'en vient.

Si il serait dans l'autre sens, vous avez toujours de scan à la fin de la ligne pour voir la nullité de vérifier, de les laisser vous tombez pour une deuxième afin de trouver ce genre de vérification est faite. Alors peut-être la coloration syntaxique peut vous aider, mais vous êtes toujours plus lente lorsque ces mots clés sont à la fin de la ligne au lieu de l'avant.

Answer 4

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

Remarquez l'utilisation d'un signe égal unique ici, ce qui signifie que le code affectera 1 à la variable i, puis renverra 1 (une affectation est une expression) et utilisera 1 dans l'instruction if, qui sera traité comme true. En d'autres termes, ce qui précède est un bug.

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

Answer 5

Dans les temps anciens, les gens seraient oublier le '!' (ou le supplément '=' pour l'égalité, ce qui est plus difficile à repérer) et de faire une affectation au lieu d'une comparaison. mettre le nul devant supprime la possibilité pour le bug, depuis null n'est pas une l-value (I. E. il ne peut pas être attribué à).

Plus les compilateurs modernes de donner un avertissement lorsque vous faites une affectation dans une condition de nos jours, et de C#, de fait, donne une erreur. La plupart des gens il suffit de coller avec la var == null régime car il est plus facile à lire pour certaines personnes.