Dlaczego często widzi się „null! = Zmienna” zamiast „zmienna! = Null” w C #?

Czy w języku c # jest jakaś różnica w szybkości wykonania w kolejności, w której określasz stan?

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

Od niedawna pierwszy z nich widziałem dość często i przykuł moją uwagę, bo do drugiego przywykłem.

Jeśli nie ma różnicy, jaka jest zaleta pierwszego?

Jest to wstrzymanie ze strony C. W C, jeśli używasz złego kompilatora lub nie masz wystarczająco wysokich ostrzeżeń, skompilujesz się bez żadnego ostrzeżenia (i rzeczywiście jest to legalny kod):

// Probably wrong
if (x = 5)

kiedy prawdopodobnie miałeś na myśli

if (x == 5)

Możesz obejść ten problem w C, wykonując:

if (5 == x)

Literówka tutaj spowoduje nieprawidłowy kod.

Teraz w C # to wszystko jest bzdury. O ile nie porównujesz dwóch wartości logicznych (co jest rzadkie, IME), możesz napisać bardziej czytelny kod, ponieważ instrukcja „if” wymaga wyrażenia boolowskiego na początku, a typ „ x=5” to Int32nie Boolean.

Proponuję, aby jeśli zobaczysz to w kodzie swoich kolegów, wyedukuj ich w zakresie języków współczesnych i zasugeruj, aby w przyszłości pisali bardziej naturalną formę.

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

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

Użycie jako nullpierwsze powoduje użycie domyślnego komparatora równości i faktycznie robi to, co zamierzałeś.

(Słyszałem, że w końcu przyzwyczaisz się do czytania kodu napisanego w ten sposób - po prostu jeszcze nie doświadczyłem 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
    }
}

Jak wszyscy już zauważyli, pochodzi on mniej więcej z języka C, w którym można uzyskać fałszywy kod, jeśli przypadkowo zapomnisz o drugim znaku równości. Ale jest jeszcze jeden powód, który pasuje również do C #: czytelność.

Weźmy po prostu 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 zamieniasz wszystkie puste słowa na początek, możesz znacznie łatwiej wykryć wszystkie sprawdzenia:

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 dotyczące kodowania), ale pomyśl tylko o szybkim przewijaniu całego pliku kodu. Po prostu widząc wzór

if(null ...

od razu wiesz, co będzie dalej.

Jeśli byłoby odwrotnie, zawsze musisz skanować do końca wiersza, aby zobaczyć sprawdzenie nieważności, pozwalając tylko na chwilę potknięcia się, aby dowiedzieć się, jaki rodzaj czeku jest tam wykonywany. Może więc podświetlanie składni może ci pomóc, ale zawsze jesteś wolniejszy, gdy te słowa kluczowe znajdują się na końcu linii, a nie na początku.

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

W C możesz napisać:

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

Zwróć uwagę na użycie w tym miejscu 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 prawda. Innymi słowy, powyższe jest błędem.

Jednak w C # nie jest to możliwe. Rzeczywiście nie ma między nimi różnicy.

Wcześniej ludzie zapominali znak „!” (lub dodatkowe „=” dla równości, które jest trudniejsze do wykrycia) i wykonaj zadanie zamiast porównania. umieszczenie wartości null na początku eliminuje możliwość wystąpienia błędu, ponieważ null nie jest wartością l (tj. nie można jej przypisać).

Większość współczesnych kompilatorów wyświetla ostrzeżenie, gdy wykonujesz przypisanie warunkowe w dzisiejszych czasach, a C # faktycznie wyświetla błąd. Większość ludzi po prostu trzyma się schematu var == null, ponieważ dla niektórych jest on łatwiejszy do odczytania.

Nie widzę żadnej korzyści z przestrzegania tej konwencji. W C, gdzie nie istnieją typy boolowskie, warto pisać

if( 5 == variable)

zamiast

if (variable == 5)

ponieważ jeśli zapomnisz o jednym ze znaków równości, skończysz z

if (variable = 5)

która przypisuje 5 zmiennej i zawsze daje wartość true. Ale w Javie wartość logiczna to wartość logiczna. A z! = W ogóle nie ma powodu.

Dobra rada to jednak pisać

if (CONSTANT.equals(myString))

zamiast

if (myString.equals(CONSTANT))

ponieważ pomaga uniknąć wyjątków NullPointerExceptions.

Radziłbym poprosić o uzasadnienie reguły. Jeśli nie ma, po co go śledzić? To nie poprawia czytelności

Dla mnie zawsze był to, jaki styl wolisz

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

Jak wielu zauważyło, głównie w starym kodzie C był używany do identyfikacji błędu kompilacji, ponieważ kompilator zaakceptował to jako legalne

Nowy język programowania, taki jak java, go, jest wystarczająco inteligentny, aby wychwycić takie błędy kompilacji

Nie należy używać warunków w kodzie „null! = Variable”, ponieważ jest to bardzo nieczytelne

Jeszcze jedno ... Jeśli porównujesz zmienną ze stałą (liczbą całkowitą lub ciągiem na przykład), 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();
}

natomiast

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

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