object == null ou null == object?

J'ai entendu quelqu'un qui null == objectvaut mieux que object == null vérifier

par exemple :

void m1(Object obj ) {
   if(null == obj)  // Is this better than object == null ? Why ?
       return ;
   // Else blah blah
}

Y a-t-il des raisons ou est-ce un autre mythe? Merci pour l'aide.

C'est probablement une habitude apprise de C, pour éviter ce genre de faute de frappe (simple =au lieu d'un double ==):

if (object = null) {

La convention consistant à placer la constante sur le côté gauche de ==n'est pas vraiment utile en Java car Java nécessite que l'expression dans un ifévalue à une booleanvaleur, donc à moins que la constante ne soit a boolean, vous obtiendriez une erreur de compilation de toute façon arguments. (et si c'est un booléen, vous ne devriez pas utiliser de ==toute façon ...)

Comme d'autres l'ont dit, c'est une habitude apprise de C pour éviter les fautes de frappe - même si même en C, je m'attendrais à des compilateurs décents à des niveaux d'avertissement suffisamment élevés pour donner un avertissement. Comme le dit Chandru, comparer avec null en Java de cette manière ne poserait des problèmes que si vous utilisiez une variable de type Boolean(que vous n'êtes pas dans l'exemple de code). Je dirais que c'est une situation assez rare, et pas une pour laquelle il vaut la peine de changer la façon dont vous écrivez du code partout ailleurs. (Je ne prendrais pas la peine d'inverser les opérandes même dans ce cas; si je réfléchis suffisamment clairement pour envisager de les inverser, je suis sûr que je peux compter les signes égaux.)

Ce qui n'a pas été mentionné, c'est que beaucoup de gens (moi y compris certainement) trouvent que le if (variable == constant)formulaire est plus lisible - c'est une façon plus naturelle de s'exprimer. C'est une raison pour ne pas copier aveuglément une convention de C. Vous devriez toujours remettre en question les pratiques (comme vous le faites ici :) avant de supposer que ce qui peut être utile dans un environnement l'est dans un autre.

Cela n'a pas beaucoup de valeur en Java (1.5+) sauf lorsque le type d'objet l'est Boolean. Dans ce cas, cela peut toujours être pratique.

if (object = null)n'entraînera pas d'échec de compilation dans Java 1.5+ si l'objet est Booleanmais lèverait un NullPointerExceptionà l'exécution.

En Java, il n'y a pas de bonne raison.

Quelques autres réponses ont affirmé que c'est parce que vous pouvez accidentellement en faire une affectation au lieu de l'égalité. Mais en Java, vous devez avoir un booléen dans un if, donc ceci:

if (o = null)

ne compilera pas.

Le seul moment où cela pourrait avoir une importance en Java est si la variable est booléenne:

int m1(boolean x)
{
    if (x = true)  // oops, assignment instead of equality

Ceci est également étroitement lié à:

if ("foo".equals(bar)) {

ce qui est pratique si vous ne voulez pas traiter avec des NPE:

if (bar!=null && bar.equals("foo")) {

Cette astuce est censée éviter les v = nulltypes de fautes de frappe.

Mais Java n'autorise que les expressions booléennes comme if()conditions de sorte que cette astuce n'a pas beaucoup de sens, le compilateur trouvera quand même ces fautes de frappe.

C'est toujours une astuce précieuse pour le code C / C ++.

Pour la même raison, vous le faites en C; affectation est une expression, vous mettez donc le littéral à gauche pour ne pas pouvoir l'écraser si vous l'utilisez accidentellement à la =place de ==.

C'est pour les personnes qui préfèrent avoir la constante sur le côté gauche. Dans la plupart des cas, avoir la constante sur le côté gauche empêchera NullPointerException d'être levée (ou d'avoir un autre contrôle nul). Par exemple, la méthode String equals effectue également une vérification nulle. Avoir la constante à gauche vous empêchera d'écrire le chèque supplémentaire. Ce qui, d'une autre manière, est également effectué plus tard. Avoir la valeur nulle sur la gauche est juste cohérent.

comme:

 String b = null;
 "constant".equals(b);  // result to false
 b.equals("constant");  // NullPointerException
 b != null && b.equals("constant");  // result to false

C'est la condition Yoda qui écrit de manière différente

En java

String myString = null;
if (myString.equals("foobar")) { /* ... */ } //Will give u null pointer

état de Yoda

String myString = null;
if ("foobar".equals(myString)) { /* ... */ } // will be false 

Comparez avec le code suivant:

    String pingResult = "asd";
    long s = System.nanoTime ( );
    if ( null != pingResult )
    {
        System.out.println ( "null != pingResult" );
    }
    long e = System.nanoTime ( );
    System.out.println ( e - s );

    long s1 = System.nanoTime ( );
    if ( pingResult != null )
    {
        System.out.println ( "pingResult != null" );
    }
    long e1 = System.nanoTime ( );
    System.out.println ( e1 - s1 );

Sortie (après plusieurs exécutions):

null != pingResult
325737
pingResult != null
47027

Par conséquent, pingResult != nullest le gagnant.

En raison de sa propriété commutative , la seule différence entre object == nullet null == object(la version Yoda ) est de nature cognitive : comment le code est lu et digéré par le lecteur. Je ne connais pas la réponse définitive, mais je sais que je préfère personnellement comparer l'objet que j'inspecte à autre chose, plutôt que de comparer autre chose à l'objet que j'inspecte , si cela a un sens. Commencez par le sujet, puis la valeur à laquelle le comparer.

Dans certaines autres langues, ce style de comparaison est plus utile.

Pour se prémunir contre un signe "=" manquant en général, je pense que l'écriture null == objectest un acte malavisé de programmation défensive . La meilleure façon de contourner ce code particulier est de garantir le comportement avec un test junit. N'oubliez pas que l'erreur possible de manquer un "=" ne dépend pas des arguments d'entrée de la méthode - vous n'êtes pas dépendant de la bonne utilisation de cette API par d'autres personnes - donc un test junit est parfait pour se prémunir contre cela. Quoi qu'il en soit, vous voudrez écrire des tests junit pour vérifier le comportement; un "=" manquant entre naturellement dans le champ d'application.