oggetto == null o null == oggetto?

Ho sentito da qualcuno che null == objectè meglio che object == null controllare

per esempio :

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

Ci sono ragioni o questo è un altro mito? Grazie per l'aiuto.

Questa è probabilmente un'abitudine appresa da C, per evitare questo tipo di errore di battitura (singolo =anziché doppio ==):

if (object = null) {

La convenzione di mettere la costante sul lato sinistro di ==non è molto utile in Java poiché Java richiede che l'espressione in un ifrestituisca un booleanvalore, quindi a meno che la costante non sia a boolean, si otterrebbe un errore di compilazione in entrambi i modi in cui si inserisce il argomenti. (e se è un booleano, non dovresti usare ==comunque ...)

Come altri hanno già detto, è un'abitudine appresa da C evitare errori di battitura, sebbene anche in C mi aspetterei compilatori decenti con livelli di avviso sufficientemente alti da fornire un avviso. Come dice Chandru, il confronto con null in Java in questo modo causerebbe problemi solo se si stesse utilizzando una variabile di tipo Boolean(che non si trova nel codice di esempio). Direi che è una situazione piuttosto rara e per cui non vale la pena cambiare il modo in cui scrivi il codice ovunque. (Non mi preoccuperei di invertire gli operandi anche in questo caso; se sto pensando abbastanza chiaramente da considerare di invertirli, sono sicuro di poter contare i segni di uguale.)

Ciò che non è stato menzionato è che molte persone (me compresa certamente) trovano il if (variable == constant)modulo più leggibile - è un modo più naturale di esprimersi. Questa è una ragione per non copiare ciecamente una convenzione da C. Dovresti sempre mettere in discussione le pratiche (come stai facendo qui :) prima di presumere che ciò che può essere utile in un ambiente sia utile in un altro.

Questo non ha molto valore in Java (1.5+) tranne quando il tipo di oggetto è Boolean. In tal caso, questo può ancora essere utile.

if (object = null)non causerà errori di compilazione in Java 1.5+ se l'oggetto è Booleanma lancerà un errore in NullPointerExceptionfase di esecuzione.

In Java non c'è una buona ragione.

Un paio di altre risposte hanno affermato che è perché puoi accidentalmente assegnarlo invece di uguaglianza. Ma in Java, devi avere un booleano in un if, quindi questo:

if (o = null)

non verrà compilato.

L'unica volta che questo potrebbe avere importanza in Java è se la variabile è booleana:

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

Questo è anche strettamente correlato a:

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

il che è conveniente se non vuoi occuparti delle NPE:

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

Questo trucco dovrebbe prevenire il v = nulltipo di errori di battitura.

Ma Java consente solo espressioni booleane come if()condizioni, quindi quel trucco non ha molto senso, il compilatore troverà comunque quegli errori di battitura.

Tuttavia, è ancora un trucco prezioso per il codice C / C ++.

Per lo stesso motivo lo fai in C; assegnazione è un'espressione, quindi metti il ​​letterale a sinistra in modo da non poterlo sovrascrivere se usi accidentalmente al =posto di ==.

Questo è per le persone che preferiscono avere la costante sul lato sinistro. Nella maggior parte dei casi, avere la costante sul lato sinistro impedirà la generazione di NullPointerException (o di avere un altro nullcheck). Ad esempio, il metodo String equals esegue anche un controllo null. Avere la costante a sinistra ti impedirà di scrivere l'assegno aggiuntivo. Che, in un altro modo, viene eseguito anche in seguito. Avere il valore nullo a sinistra significa semplicemente essere coerenti.

piace:

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

È la condizione di Yoda che scrive in modo diverso

In java

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

yoda condizione

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

Confronta con il codice seguente:

    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 );

Output (dopo più esecuzioni):

null != pingResult
325737
pingResult != null
47027

Pertanto, pingResult != nullè il vincitore.

A causa della sua proprietà commutativa , l'unica differenza tra object == nulle null == object(la versione Yoda ) è di natura cognitiva : come il codice viene letto e digerito dal lettore. Non conosco la risposta definitiva, ma so che personalmente preferisco confrontare l'oggetto che sto ispezionando con qualcos'altro, piuttosto che confrontare qualcos'altro con l'oggetto che sto ispezionando , se ha senso. Inizia con il soggetto, quindi il valore con cui confrontarlo.

In alcune altre lingue questo stile di confronto è più utile.

Per difendersi dal segno "=" mancante in generale, però, penso che scrivere null == objectsia un atto di programmazione difensiva fuorviante . Il modo migliore per aggirare questo particolare codice è garantire il comportamento con un test junit. Ricorda, il possibile errore di perdere un "=" non dipende dagli argomenti di input del metodo - non sei dipendente dall'uso corretto di questa API da parte di altre persone - quindi un test junit è perfetto per proteggersi da quello. Comunque vorrai scrivere dei test junit per verificare il comportamento; un "=" mancante rientra naturalmente nell'ambito.