объект == null или null == объект?

Я слышал от кого-то, что null == objectлучше, чем object == null проверить

например:

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

Есть ли причины или это очередной миф? Спасибо за помощь.

Вероятно, это привычка, полученная от C, чтобы избежать такой опечатки (одиночной =вместо двойной ==):

if (object = null) {

Соглашение о помещении константы в левой части ==не очень полезно в Java, поскольку Java требует, чтобы выражение в ifоценке оценивалось как booleanзначение, поэтому, если константа не является a boolean, вы получите ошибку компиляции в любом случае, если вы поместите аргументы. (и если это логическое значение, вам ==все равно не следует использовать ...)

Как говорили другие, это привычка, которую выучили у C, избегать опечаток - хотя даже в C я ожидал бы, что достойные компиляторы при достаточно высоких уровнях предупреждений выдадут предупреждение. Как говорит Чандру, сравнение с null в Java таким способом вызовет проблемы только в том случае, если вы используете переменную типа Boolean(которой нет в примере кода). Я бы сказал, что это довольно редкая ситуация, и не та, для которой стоит менять способ написания кода в любом другом месте. (Я бы не стал обращать внимание на операнды даже в этом случае; если я достаточно ясно мыслю, чтобы рассмотреть возможность их изменения, я уверен, что могу посчитать знаки равенства.)

Что не было упомянуто, так это то, что многие люди (в том числе и я, конечно) находят if (variable == constant)форму более читаемой - это более естественный способ самовыражения. Это причина не копировать слепо соглашение из C. Вы всегда должны подвергать сомнению практики (как вы делаете здесь :), прежде чем предполагать, что то, что может быть полезно в одной среде, полезно в другой.

В Java (1.5+) это не имеет особого значения, за исключением случаев, когда объект имеет тип Boolean. В таком случае это все еще может пригодиться.

if (object = null)не вызовет сбоя компиляции в Java 1.5+, если объект есть, Booleanно вызовет ошибку во NullPointerExceptionвремя выполнения.

В Java нет веской причины.

В нескольких других ответах утверждалось, что это потому, что вы можете случайно назначить его вместо равенства. Но в Java у вас должно быть логическое значение в if, поэтому это:

if (o = null)

не будет компилироваться.

Единственный раз, когда это может иметь значение в Java, - это если переменная является логической:

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

Это также тесно связано с:

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

что удобно, если вы не хотите иметь дело с NPE:

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

Этот трюк призван предотвратить v = nullопечатки.

Но Java допускает только логические выражения в качестве if()условий, так что этот трюк не имеет особого смысла, компилятор все равно обнаружит эти опечатки.

Тем не менее, это по-прежнему ценный трюк для кода C / C ++.

По той же причине, по которой вы делаете это в C; присваивание - это выражение, поэтому вы помещаете литерал слева, чтобы его нельзя было перезаписать, если вы случайно используете =вместо ==.

Это для людей, которые предпочитают, чтобы константа была слева. В большинстве случаев наличие константы в левой части предотвратит выброс исключения NullPointerException (или другой нулевой контроль). Например, метод String также выполняет нулевую проверку. Наличие константы слева не даст вам выписать дополнительный чек. Что, по-другому, тоже выполняется позже. Наличие нулевого значения слева - это просто согласованность.

лайк:

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

Это условие Йоды, написанное по-другому

В Java

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

состояние йода

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

Сравните со следующим кодом:

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

Вывод (после многократного выполнения):

null != pingResult
325737
pingResult != null
47027

Следовательно, pingResult != nullэто победитель.

Из-за его коммутативности единственное различие между object == nullи null == object( версия Йоды ) носит когнитивный характер : как код читается и усваивается читателем. Я не знаю окончательного ответа, но знаю, что лично предпочитаю сравнивать проверяемый мной объект с чем-то другим, а не сравнивать что-то еще с объектом, который я проверяю , если это имеет смысл. Начните с предмета, а затем значения, с которым его нужно сравнить.

В некоторых других языках этот стиль сравнения более полезен.

Однако, чтобы обезопасить себя от отсутствия знака «=» в целом, я считаю, что написание null == objectявляется ошибочным актом защитного программирования . Лучший способ обойти этот конкретный код - гарантировать поведение с помощью теста junit. Помните, что возможная ошибка отсутствия знака "=" не зависит от входных аргументов метода - вы не зависите от правильного использования этого API другими людьми - поэтому тест junit идеально подходит для защиты от этого. В любом случае вы захотите написать тесты junit для проверки поведения; отсутствующий знак "=" естественно попадает в область действия.