Por que costumamos ver “null! = Variable” em vez de “variable! = Null” em C #?

Em c #, há alguma diferença na velocidade de execução para a ordem em que você declara a condição?

if (null != variable) ...
if (variable != null) ...

Recentemente, vi o primeiro com bastante frequência, e isso me chamou a atenção porque estava acostumado com o segundo.

Se não houver diferença, qual a vantagem do primeiro?

É um resquício de C. Em C, se você usar um compilador ruim ou não tiver avisos altos o suficiente, isso será compilado sem nenhum aviso (e é de fato um código legal):

// Probably wrong
if (x = 5)

quando você provavelmente quis dizer

if (x == 5)

Você pode contornar isso em C fazendo:

if (5 == x)

Um erro de digitação aqui resultará em código inválido.

Agora, em C #, isso é tudo tolice. A menos que você esteja comparando dois valores booleanos (o que é raro, IME), você pode escrever o código mais legível, pois uma instrução "if" requer uma expressão booleana para começar, e o tipo de " x=5" Int32não é Boolean.

Eu sugiro que, se você vir isso no código de seus colegas, você os eduque nas formas das linguagens modernas e sugira que escrevam a forma mais natural no futuro.

Há um bom motivo para usar nulo primeiro: if(null == myDuck)

Se você class Ducksubstitui o ==operador, if(myDuck == null)pode entrar em um loop infinito.

Usar nullprimeiro usa um comparador de igualdade padrão e realmente faz o que você pretendia.

(Ouvi dizer que você se acostuma a ler código escrito dessa maneira - só não experimentei essa transformação ainda).

Aqui está um exemplo:

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
    }
}

Como todo mundo já notou, ele vem mais ou menos da linguagem C, onde você pode obter um código falso se acidentalmente esquecer o segundo sinal de igual. Mas há outro motivo que também corresponde ao C #: legibilidade.

Veja este exemplo simples:

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

Se você simplesmente trocar todas as palavras nulas para o início, poderá identificar com muito mais facilidade todas as verificações:

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

Portanto, este exemplo pode ser um mau exemplo (consulte as diretrizes de codificação), mas pense em rolar rapidamente por um arquivo de código completo. Simplesmente vendo o padrão

if(null ...

você sabe imediatamente o que está por vir.

Se fosse o contrário, você sempre teria que escanear até o final da linha para ver o cheque de nulidade, apenas deixando você cambalear por um segundo para descobrir que tipo de cheque é feito lá. Então, talvez o realce de sintaxe possa ajudá-lo, mas você sempre é mais lento quando essas palavras-chave estão no final da linha em vez de na frente.

Eu acho que este é um programador C que mudou de idioma.

Em C, você pode escrever o seguinte:

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

Observe o uso de um único sinal de igual aqui, o que significa que o código atribuirá 1 à variável i, em seguida, retornará 1 (uma atribuição é uma expressão) e usará 1 na instrução if, que será tratada como verdadeira. Em outras palavras, o acima é um bug.

Em C #, entretanto, isso não é possível. Na verdade, não há diferença entre os dois.

Antigamente, as pessoas esqueceriam o '!' (ou o extra '=' para igualdade, que é mais difícil de detectar) e faça uma atribuição em vez de uma comparação. colocar o nulo na frente elimina a possibilidade do bug, já que nulo não é um valor l (ou seja, ele não pode ser atribuído).

A maioria dos compiladores modernos dá um aviso quando você faz uma atribuição em uma condicional hoje em dia, e o C # na verdade fornece um erro. A maioria das pessoas apenas segue o esquema var == null, pois é mais fácil de ler para algumas pessoas.

Não vejo nenhuma vantagem em seguir esta convenção. Em C, onde não existem tipos booleanos, é útil escrever

if( 5 == variable)

ao invés de

if (variable == 5)

porque se você esquecer um dos sinais de equal, você acaba com

if (variable = 5)

que atribui 5 à variável e sempre avalia como verdadeiro. Mas em Java, um booleano é um booleano. E com! =, Não há razão alguma.

Um bom conselho, porém, é escrever

if (CONSTANT.equals(myString))

ao invés de

if (myString.equals(CONSTANT))

porque ajuda a evitar NullPointerExceptions.

Meu conselho seria pedir uma justificativa para a regra. Se não há nenhum, por que segui-lo? Não ajuda na legibilidade

Para mim sempre foi o estilo que você prefere

@Shy - Então, novamente, se você confundir os operadores, deverá obter um erro de compilação ou estará executando o código com um bug - um bug que volta e o morde mais tarde, pois produziu um comportamento inesperado

Como muitos apontaram, é principalmente em código C antigo que era usado para identificar erros de compilação, já que o compilador o aceitava como legal

Novas linguagens de programação como java, go são inteligentes o suficiente para capturar tais erros de compilação

Não se deve usar "null! = Variable" como condições no código, pois é muito ilegível

Mais uma coisa ... Se você estiver comparando uma variável a uma constante (inteiro ou string, por exemplo), colocar a constante à esquerda é uma boa prática porque você nunca encontrará NullPointerExceptions:

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

enquanto que

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

Agora, como por padrão o C # instancia todas as variáveis, você não deve ter esse problema nessa linguagem.