Jaka jest różnica między tymi (bCondition == NULL) i (NULL == bCondition)?

Question

Podczas eksploracji witryn msdn, większość warunków sprawdza miejsca, z których korzystają (NULL == bCondition).

jaki jest cel używania tych oznaczeń?

Podaj próbkę, aby to wyjaśnić.

Dzięki.

Answer 1

Zastosowanie NULL == condition zapewnia bardziej użyteczne działanie w przypadku typo, gdy operator przypisania = ta zostanie przypadkowo użyta, a następnie operator porównanie ==:

if (bCondition = NULL) // typo here 
{ 
// code never executes 
} 

if (NULL = bCondition) // error -> compiler complains 
{ 
// ... 
} 

kompilator C daje ostrzeżenia w pierwszym przypadku, nie ma takich ostrzeżeń w wielu językach.

Answer 2

Wiele osób woli pisać NULL == bCondition, aby przypadkowo nie przypisać wartości NULL do bCondition.

powodu literówki zdarza się, że zamiast pisać

bCondition == NULL 

one skończyć pisanie

bCondition = NULL // the value will be assigned here. 

w przypadku

NULL = bCondition // there will be an error 

Answer 3

To po prostu dobry środek obronny. Niektórym może również wygodniej czytać. W przypadku błędnego przypisania zamiast operatora równości, kompilator spróbuje zmodyfikować NULL, który nie jest lwartością i spowoduje wyświetlenie komunikatu o błędzie. Podczas korzystania z bCondition = NULL kompilator może wygenerować ostrzeżenie o użyciu przypisania jako wartości prawdziwej, wiadomości, która może zostać zgubiona i niezauważona.

Answer 4

Nazywa się Yoda Conditions. (The original link, potrzebujesz wysokiego powtórzenia, aby go zobaczyć).

Jest przeznaczony do ochrony przed przypadkowym przeniesieniem = w warunkach, w których zamierzano dokonać porównania równości ==. Jeśli trzymasz się Yody przez nawyk i robisz literówkę pisząc = zamiast ==, kod nie powiedzie się, ponieważ nie możesz przypisać do wartości r.

Czy to jest warte niezręczności? Niektórzy nie zgadzają się, mówiąc, że kompilatory wyświetlają ostrzeżenie, gdy widzą wyrażenia warunkowe w postaci =. Mówię, że po prostu popełniłem ten błąd dwa lub trzy razy w ciągu mojego życia, co nie usprawiedliwia zmiany wszystkich MLOC, które napisałem w moim życiu na tę konwencję.

Answer 5

Nie ma różnicy. To starożytna metoda programowania obronnego, która od ponad 20 lat jest przestarzała. Celem było zabezpieczenie przed przypadkowym wpisaniem = zamiast == przy porównywaniu dwóch wartości. Pasjansowi programiści migrujący do C byli szczególnie skłonni do napisania tego błędu.

Od Borland Turbo C wydany w 1990 roku i do przodu, każdy znany kompilator ostrzega przed "prawdopodobnie niepoprawnym przypisaniem", kiedy uda ci się wpisać ten błąd.

Zatem pisanie (NULL == bCondition) nie jest lepszą lub gorszą praktyką niż odwrotnie, chyba że twój kompilator jest bardzo stary. Nie musisz się martwić o pisanie ich w dowolnej kolejności.

Co powinny przejmuj się, jest dostosowanie stylu kodowania, gdzie nigdy zapisu zadania wewnątrz pętli IF/warunki. Nigdy nie ma powodu, aby to robić. Jest to całkowicie zbędna, ryzykowna i brzydka cecha języka C. Wszystkie branżowe standardy kodowania de facto zakazują przydziału w warunkach.

Referencje:

• MISRA C: 2004 13,1
• CERT C EXP18-C

Answer 6

Podczas zwykle nie ma różnicy między variable == value i value == variable, aw zasadzie nie powinnam” T być, w C++ czasami może być różnica w ogólnym przypadku, jeśli w grę wchodzi przeciążenie operatora. Na przykład, chociaż oczekuje się, że == będzie symetryczny, ktoś mógłby napisać patologiczną implementację, która nie jest.

Klasa string Microsoft _bstr_t ma problem z asymetrią w implementacji operator==.