Différence nulle

Question

Quelle est la différence entre

if(null==object) 

et

if(object==null) 

S'il vous plaît donner l'avantage à l'utilisation ci-dessus.

Answer 1

La différence vient si vous tapez accidentellement = au lieu de ==:

if (null = object) - erreur du compilateur
if (object = null) - Bug!

Answer 2

Aucune différence. (null == object) est une pratique de C/C++, où "=" est à la fois utilisé comme opérateur d'affectation, et comme opérateur de comparaison.

Il y avait trop d'erreurs si if (objet = null) était utilisé.

Answer 3

Certains préfèrent if (null == object) de sorte que si vous tapez accidentellement = au lieu de ==, vous obtenez une erreur de compilation au lieu d'une affectation.

Answer 4

Logiquement, il n'y a pas de différence.

d'une erreur vérification point de vue, la première est plus souhaitable, car si vous manquez un signe égal (=), le compilateur vous permettra de savoir que vous ne pouvez pas faire une cession à une constante.

Answer 5

Dans de nombreux langages == est l'opérateur de comparaison = est l'opérateur d'affectation.

Il est très facile de taper = quand vous voulez vraiment dire ==.

Par conséquent, la convention de typage constant == variable est préférée. Constant = variable ne compilera pas, vous indiquant ainsi votre erreur.

Variable = constante compilera et fera la mauvaise chose au moment de l'exécution.

Answer 6

Eh bien, voici quelque chose que je peu comme ... utiliser des extensions:

public static class ObjectExtensions 
{ 
    public static bool IsNull(this object target) 
    { 
     return null == target; 
    } 
} 

Maintenant, vous pouvez oublier complètement:

if(item.IsNull()) 

Answer 7

Dans le bon vieux temps, compilateurs serait heureusement vous permettre de faire des affectations à l'intérieur de conditions, conduisant à des erreurs involontaires:

if(a = false) 
{ 
    // I'll never execute 
} 
if(b = null) 
{ 
    // I'll never execute 
} 
b.Method(); // And now I'm null! 

Ainsi, certains développement intelligent rs ont commencé à mettre leurs constantes en premier dans leurs conditions:

if(false = a) // OOPS! Compiler error 
{ 
    // .. 
} 
if(null = b) // OOPS! Compiler error 
{ 
    // .. 
} 

Ainsi, ils se sont entraînés pour éviter toute une classe d'erreurs. La plupart des compilateurs modernes ne vous laisseront plus faire cette erreur, mais la pratique continue.

Il y a un autre avantage à mettre toujours d'abord vos constantes:

if(myString != null && myString.Equals("OtherString")) 
{ 
    // ... 
} 

peut (en .NET, Java, et la plupart des langages avec un type de chaîne à base d'objets) être réduite à:

if("OtherString".Equals(myString)) 
{ 
    // .. 
}