Gdyby null być sprawdzane po stronie lewej lub prawej

Question

Przeglądając jakiś kod, widziałem:

if (null == condition) { ... } 

i widziałem też:

if (condition == null) { ... } 

wydaje mi się, że nie ma zaletą posiadania po lewej stronie, ale nie pamiętam tego i myślałem, że jest to starszy element środowiska wykonawczego, który został zoptymalizowany za pomocą nowszych środowisk wykonawczych .NET. Zwykle używam tego ostatniego testu zerowego, więc ten pierwszy wpada mi w oko.

Czy jest to kwestia stylu, czy też istnieje korzyść z posiadania null po lewej lub prawej stronie oceny?

Answer 1

Może to zrobić różnicę e w trzech przypadkach.

Jednym z nich jest przypadek, w którym literówka condition = null jest ważna w if. Jest to bardziej powszechne w językach w stylu C, które pozwoliłyby na null w if (ceniony jako false), który jest większość z nich, ale nie C#.

Jest możliwe, aby stworzyć typ, który ma ten skutek w C#:

public class Test 
{ 
    public static bool operator true(Test x) 
    { 
    return true; 
    } 
    public static bool operator false(Test x) 
    { 
    return false; 
    } 
} 
void Main() 
{ 
    Test test = new test(); 
    if (test = null) 
    { 
    Console.WriteLine("!"); 
    } 
} 

Nie ma wiele razy, że przeciążenia tych operatorów sensu, zwłaszcza, że ​​.NET 2.0 wprowadzone leki generyczne (miał większą wartość dla typów takich jak SqlBoolean, które włączały wartość, aby wskazać true, false lub null w sposób, w jaki używamy teraz bool?).

Ta sprawa jest dość marginalna w języku C#.

Innym jest podobna, jeśli istnieje niejawna konwersja do bool lub do typu, który z kolei realizuje true i false operatory:

void Main() 
{ 
    Test test = new Test(); 
    if (test = null) 
    { 
    Console.WriteLine("!"); 
    } 
} 
public class Test 
{ 
    public static implicit operator bool(Test x) 
    { 
    return true; 
    } 
} 

operatorzy niejawne są warte unikanie z kilku powodów, ale jest to nieco bardziej prawdopodobny niż pierwszy przykład, choć nadal nie jest powszechny.

Jeszcze inna jest sytuacja, gdy == jest przeciążony w niesymetrycznej sposób:

public class Test 
{ 
    public static bool operator == (Test x, Test y) 
    { 
    return ReferenceEquals(x, null); 
    } 
    public static bool operator !=(Test x, Test y) 
    { 
    return !(x == y); 
    } 
} 
void Main() 
{ 
    Test test = new Test(); 
    if (test == null) 
    { 
    Console.WriteLine("This won't print."); 
    } 
    if (null == test) 
    { 
    Console.WriteLine("This will print."); 
    } 
} 

Ale ponieważ niesymetryczną == zawsze jest bug, to zależy od błędu w operatorze mieć żadnego wpływu . Prawdopodobnie zdarza się to nieco częściej niż pierwszy przypadek, ale powinno zostać naprawione, gdy tak się stanie, a więc jest jeszcze mniej realne.

Podczas gdy może mieć efekt w języku C#, sprawy są rzadkie i w większości oparte na tym, że ktoś zrobił coś, czego nie powinien.

Jako taka, jest to głównie kwestia stylu. Ludzie, którzy najpierw wstawili plik null, wybierali go z języków, z których robi się różnicę.

Answer 2

Klasycznym powodem używania języków w stylu C jest ochrona przed błędnym wpisaniem równości == jako przypisania =. Nie można przypisać do stałej - czyli po to nielegalne, a więc kompilator złapie bakcyla:

if (false = condition) { ... } 

natomiast jest to całkowicie legalne (ale chyba nie ma co autor:

if (condition = false) { ... } 

Uwaga: Ten problem jest ograniczony w C# (w porównaniu do wanilii C), ponieważ instrukcje if wymagają instrukcji bool (jak zaznaczono w komentarzach poniżej), więc jedyny przypadek, który faktycznie powoduje problemy, jest taki, że typem jest bool.

Answer 3

Niezależnie od tego, w jaki sposób zestawia (null == condition), stosując przykładowe wartości jak null jako pierwszy (po lewej) argumentu jest wbrew intuicji. Zamiast tego pierwszy operand powinien zasugerować, co zamierzasz ocenić.