objeto == nulo ou nulo == objeto?

Eu ouvi de alguém que null == objecté melhor do que object == null verificar

por exemplo :

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

Existe alguma razão ou este é outro mito? Obrigado pela ajuda.

Este é provavelmente um hábito aprendido com C, para evitar este tipo de erro de digitação (simples em =vez de duplo ==):

if (object = null) {

A convenção de colocar a constante no lado esquerdo de ==não é realmente útil em Java, pois Java requer que a expressão em um ifavalie um booleanvalor, então, a menos que a constante seja a boolean, você obteria um erro de compilação de qualquer maneira que colocasse o argumentos. (e se for um booleano, você não deveria usar de ==qualquer maneira ...)

Como outros já disseram, é um hábito aprendido com C para evitar erros de digitação - embora mesmo em C eu esperasse compiladores decentes em níveis de aviso altos o suficiente para dar um aviso. Como diz Chandru, comparar com null em Java dessa forma só causaria problemas se você estivesse usando uma variável do tipo Boolean(que não está no código de amostra). Eu diria que é uma situação muito rara, e não uma para a qual vale a pena mudar a maneira como você escreve o código em qualquer outro lugar. (Eu não me incomodaria em reverter os operandos, mesmo neste caso; se estou pensando com clareza o suficiente para considerar revertê-los, tenho certeza de que posso contar os sinais de igual).

O que não foi mencionado é que muitas pessoas (eu certamente incluído) acham o if (variable == constant)formulário mais legível - é uma forma mais natural de se expressar. Esta é uma razão para não copiar cegamente uma convenção de C. Você deve sempre questionar as práticas (como está fazendo aqui :) antes de presumir que o que pode ser útil em um ambiente é útil em outro.

Isso não tem muito valor em Java (1.5+), exceto quando o tipo de objeto é Boolean. Nesse caso, isso ainda pode ser útil.

if (object = null)não causará falha de compilação em Java 1.5+ se o objeto for, Booleanmas lançaria um NullPointerExceptionem tempo de execução.

Em Java, não há um bom motivo.

Algumas outras respostas afirmam que é porque você pode acidentalmente fazer atribuição em vez de igualdade. Mas em Java, você precisa ter um booleano em um if, então este:

if (o = null)

não vai compilar.

A única vez que isso pode importar em Java é se a variável for booleana:

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

Isso também está intimamente relacionado a:

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

o que é conveniente se você não quiser lidar com NPEs:

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

Este truque deveria evitar v = nulltipos de erros de digitação.

Mas o Java permite apenas expressões booleanas como if()condições, então esse truque não faz muito sentido, o compilador encontrará esses erros de digitação de qualquer maneira.

No entanto, ainda é um truque valioso para código C / C ++.

Pelo mesmo motivo, você faz isso em C; atribuição é uma expressão, então você coloca o literal à esquerda para que não possa sobrescrevê-lo se acidentalmente usar em =vez de ==.

Isso é para pessoas que preferem ter a constante do lado esquerdo. Na maioria dos casos, ter a constante no lado esquerdo impedirá que NullPointerException seja lançado (ou ter outro nullcheck). Por exemplo, o método String equals também faz uma verificação de nulos. Ter a constante à esquerda impedirá que você faça o cheque adicional. Que, de outra forma, também é realizado posteriormente. Ter o valor nulo à esquerda é apenas ser consistente.

gostar:

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

É a condição de Yoda, escrevendo de maneira diferente

Em java

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

condição yoda

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

Compare com o seguinte código:

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

Resultado (após várias execuções):

null != pingResult
325737
pingResult != null
47027

Portanto, pingResult != nullé o vencedor.

Por causa de sua propriedade comutativa , a única diferença entre object == nulle null == object(a versão Yoda ) é de natureza cognitiva : como o código é lido e digerido pelo leitor. Não sei a resposta definitiva, mas sei que pessoalmente prefiro comparar o objeto que estou inspecionando a outra coisa, em vez de comparar outra coisa ao objeto que estou inspecionando , se isso fizer algum sentido. Comece com o assunto e, em seguida, o valor com o qual compará-lo.

Em alguns outros idiomas, esse estilo de comparação é mais útil.

Para se proteger contra a falta de um sinal "=" em geral, porém, acho que escrever null == objecté um ato equivocado de programação defensiva . A melhor maneira de contornar esse código específico é garantir o comportamento com um teste junit. Lembre-se, o possível erro de perder um "=" não depende dos argumentos de entrada do método - você não depende do uso correto desta API por outras pessoas - então, um teste junit é perfeito para proteger contra isso. De qualquer forma, você desejará escrever testes junit para verificar o comportamento; um "=" ausente naturalmente está dentro do escopo.