object==null или null==object?

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

if (object = null) {

Соглашение о размещении константы слева от == не очень полезно в Java, поскольку Java требует, чтобы выражение в if оценивалось как значение boolean, поэтому, если константа не является 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 (или наличие другой проверки на ноль). Например, метод equals 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 (версия Yoda) носит когнитивный характер: как код читается и усваивается читателем . Я не знаю точного ответа, но знаю, что лично я предпочитаю сравнение объекта, который я проверяю, с чем-то другим, а не сравнение чего-то другого с объектом, который я проверяю, если это имеет смысл. Начните с темы, затем значения для сравнения.

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

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