Dlaczego często widzimy "null!= zmienna "zamiast" zmienna!= null " W C#?

Istnieje dobry powód, aby najpierw użyć null: if(null == myDuck)

Jeśli class Duck nadpisuje operator ==, to if(myDuck == null) może przejść do nieskończonej pętli.

Użycie null najpierw używa domyślnego komparatora równości i faktycznie robi to, co zamierzałeś.

(słyszałem, że w końcu przyzwyczaiłeś się do czytania kodu napisanego w ten sposób - po prostu nie doświadczyłem jeszcze tej transformacji).

Oto przykład:

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

Myślę, że jest to Programista C, który zmienił języki.

W C możesz napisać:

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

Zwróć uwagę na użycie pojedynczego znaku równości, co oznacza, że kod przypisze 1 do zmiennej i, a następnie zwróci 1( przypisanie jest wyrażeniem) i użyje 1 w instrukcji if, która będzie traktowana jako true. Innymi słowy, powyższe jest błędem.

W C# jednak nie jest to możliwe. Rzeczywiście nie ma różnicy między tymi dwoma.

Jak wszyscy już zauważyli, pochodzi mniej więcej z języka C, gdzie można uzyskać fałszywy Kod, jeśli przypadkowo zapomnisz drugiego znaku równości. Ale jest jeszcze inny powód, który pasuje również do C#: Readability.

Weź ten prosty przykład:

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

Jeśli po prostu zamienisz wszystkie null słowa na początek, możesz znacznie łatwiej zauważyć wszystkie kontrole:

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

Więc ten przykład jest może złym przykładem (patrz wytyczne kodowania), ale po prostu pomyśl o Tobie szybkie przewijanie całego pliku kodu. Po prostu widząc wzorzec

if(null ...

Jeśli byłoby odwrotnie, zawsze musisz zeskanować do końca linii, aby zobaczyć sprawdzenie nieważności, po prostu pozwalając ci potknąć się na sekundę, aby dowiedzieć się, jakiego rodzaju kontrola jest tam wykonywana. Więc może podświetlanie składni może Ci pomóc, ale zawsze jesteś wolniejszy, gdy te słowa kluczowe są na końcu linii, a nie na początku.

W dawnych czasach ludzie zapomnieli o'!"(lub dodatkowy " = " dla równości, który jest trudniejszy do wykrycia) i wykonać zadanie zamiast porównania. umieszczenie null Z przodu eliminuje możliwość wystąpienia błędu, ponieważ null nie jest wartością l (tzn. nie można jej przypisać).

Większość współczesnych kompilatorów daje ostrzeżenie, gdy wykonujesz zadanie w trybie warunkowym, A C# faktycznie daje błąd. Większość ludzi po prostu trzymać się schematu var = = null, ponieważ łatwiej jest poczytaj dla niektórych.

Nie widzę żadnej korzyści w stosowaniu tej konwencji. W C, gdzie typy boolean nie istnieją, warto napisać

if( 5 == variable)

Zamiast

if (variable == 5)

Ponieważ jeśli zapomnisz jednego ze znaków eaqual, skończysz z

if (variable = 5)

Który przypisuje 5 zmiennej i zawsze ocenia na true. Ale w Javie boolean to boolean. I z != , nie ma żadnego powodu.

if (CONSTANT.equals(myString))

Zamiast

if (myString.equals(CONSTANT))

Ponieważ pomaga unikanie NullPointerExceptions.

Moją radą byłoby poprosić o uzasadnienie reguły. Jeśli nie ma, to po co za tym podążać? To nie pomaga czytelność

Dla mnie zawsze był to jaki styl wolisz

@ Shy-jeśli pomylisz operatorów, powinieneś chcieć uzyskać błąd kompilacji lub będziesz uruchamiał kod z błędem - błędem, który wraca i gryzie cię później, ponieważ generuje nieoczekiwane zachowanie

Jeszcze jedno... Jeśli porównujesz zmienną ze stałą (integer lub string dla ex.), umieszczenie stałej po lewej stronie jest dobrą praktyką, ponieważ nigdy nie napotkasz 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();
}

Teraz, ponieważ domyślnie C# instancjuje wszystkie zmienne, nie powinieneś mieć tego problemu w tym języku.