Почему часто можно увидеть " null!= переменная "вместо" переменной!= null " в C#?

есть веская причина использовать сначала null:if(null == myDuck)

если class Duck переопределяет == оператора, затем if(myDuck == null) может войти в бесконечный цикл.

используя null сначала использует компаратор на равенство по умолчанию и фактически делает то, что вы замышляли.

(Я слышал, что вы привыкли читать код, написанный таким образом, в конце концов - я просто еще не испытал эту трансформацию).

вот пример:

public class myDuck
{
    public int quacks;
    static override bool operator ==(myDuck a, myDuck b)
    {
        // these will overflow the stack - because the a==null reenters this function from the top again
        if (a == null && b == null)
            return true;
        if (a == null || b == null)
            return false;

        // these wont loop
        if (null == a && null == b)
            return true;
        if (null == a || null == b)
            return false;
        return a.quacks == b.quacks; // this goes to the integer comparison
    }
}

Я думаю, что это программист C, который переключил языки.

В C, вы можете написать следующее:

int i = 0;
if (i = 1)
{
    ...
}

обратите внимание на использование там одного знака равенства, что означает, что код присвоит 1 переменной i, затем вернет 1 (присвоение является выражением) и использует 1 в операторе if, который будет обрабатываться как true. Другими словами, вышеизложенное является ошибкой.

В C# однако это невозможно. Там действительно нет никакой разницы между два.

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

просто возьмите этот простой пример:

if(someVariableThatShouldBeChecked != null
   && anotherOne != null
   && justAnotherCheckThatIsNeededForTestingNullity != null
   && allTheseChecksAreReallyBoring != null
   && thereSeemsToBeADesignFlawIfSoManyChecksAreNeeded != null)
{
    // ToDo: Everything is checked, do something...
}

Если бы вы просто поменяли все null слова к началу вы можете гораздо легче определить все проверки:

if(null != someVariableThatShouldBeChecked
   && null != anotherOne
   && null != justAnotherCheckThatIsNeededForTestingNullity
   && null != allTheseChecksAreReallyBoring
   && null != thereSeemsToBeADesignFlawIfSoManyChecksAreNeeded)
{
    // ToDo: Everything is checked, do something...
}

Так что этот пример, возможно, плохой пример (см. рекомендации по кодированию), но просто подумайте о том, что вы быстро прокручиваете полный файл кода. Просто увидев шаблон

if(null ...

вы сразу знаете, что будет дальше.

Если бы это было наоборот, вы всегда должны scan до конца строки, чтобы увидеть проверку на недействительность, просто позволяя вам споткнуться на секунду, чтобы узнать, какая проверка там сделана. Так что, возможно, подсветка синтаксиса может помочь вам, но вы всегда медленнее, когда эти ключевые слова в конце линии вместо фронта.

в прежние времена, люди забыли бы '!'(или дополнительное '=' для равенства, которое труднее определить) и выполнить задание вместо сравнения. установка null спереди исключает возможность ошибки, так как null не является l-значением (т. е. оно не может быть назначено).

большинство современных компиляторов дают предупреждение, когда вы выполняете задание в условном режиме в настоящее время, и C# фактически дает ошибку. Большинство людей просто придерживаться схемы var = = null, так как это легче читать для некоторых людей.

Я не вижу никакого преимущества в следовании этой конвенции. В C, где логические типы не существуют, полезно написать

if( 5 == variable)

, а не

if (variable == 5)

потому что если вы забудете один из знаков eaqual, вы получите

if (variable = 5)

который присваивает 5 переменной и всегда оценивает в true. Но в Java логическое значение является логическим. И с этим != , нет никакой причины вообще.

один хороший совет, однако, чтобы пиши

if (CONSTANT.equals(myString))

, а не

if (myString.equals(CONSTANT))

потому что это помогает избежать NullPointerExceptions.

мой совет состоял бы в том, чтобы попросить об обосновании этого правила. Если их нет, зачем им следовать? Это не помогает читабельности

для меня это всегда было какой стиль вы предпочитаете

@Shy-опять же, если вы путаете операторов, то вы должны хотеть получить ошибку компиляции, или вы будете запускать код с ошибкой-ошибкой, которая вернется и укусит вас позже по дороге, так как она вызвала неожиданное поведение

еще одна вещь... Если вы сравниваете переменную с константой (целое число или строка, например.), размещение константы слева-это хорошая практика, потому что вы никогда не столкнетесь с NullPointerExceptions :

int i;
if(i==1){        // Exception raised: i is not initialized. (C/C++)
  doThis();
}

, тогда как

int i;
if(1==i){        // OK, but the condition is not met.
  doThis();
}

теперь, поскольку по умолчанию c# инстанцирует все переменные, у вас не должно быть этой проблемы на этом языке.