Czy „if (0 == value)…” nie wyrządza więcej szkody niż pożytku? [Zamknięte]

Jest to jedna z rzeczy, których najbardziej nienawidzę, kiedy widzę to w czyimś kodzie. Wiem, co to znaczy i dlaczego niektórzy robią to w ten sposób („co jeśli przypadkowo wstawię„ = ”zamiast tego?”). Dla mnie bardzo przypomina to, gdy dziecko schodzi po schodach, licząc kroki na głos.

Tak czy inaczej, oto moje argumenty przeciwko niemu:

• Zakłóca naturalny przepływ odczytu kodu programu. My, ludzie, mówimy „jeśli wartość wynosi zero”, a nie „jeśli zero jest wartością”.
• Nowoczesne kompilatory ostrzegają cię, gdy masz zadanie w swoim stanie, a właściwie jeśli twój stan składa się tylko z tego zadania, które, tak, i tak wygląda podejrzanie
• Nie należy zapominać o wstawieniu podwójnego „=” podczas porównywania wartości, jeśli jesteś programistą. Równie dobrze możesz zapomnieć wpisać „!” podczas testowania nierówności.

Ach, tak, „Warunkowe Yoda” („Jeśli zero jest wartością, wykonaj ten kod, musisz!”). Każdemu, kto twierdzi, że jest „lepszy”, zawsze wskazuję narzędzia takie jak lint (1). Ten szczególny problem został rozwiązany od późnych lat 70. Większość współczesnych języków nawet nie skompiluje wyrażenia podobnego if(x = 10), ponieważ odmawiają przymusu wynikowi przypisania do wartości logicznej.

Jak powiedzieli inni, z pewnością nie jest to problem, ale wywołuje trochę dysonansu poznawczego.

Jest wstrętny, ponieważ nakłada niewielki, ale zauważalny podatek psychiczny.

Ludzie czytają od lewej do prawej w praktycznie wszystkich językach programowania (i większości języków naturalnych).

Jeśli widzę 123 == x, sposób, w jaki analizuję to w następujący sposób:

• 123- Więc co? niepełne informacje.
• == - cóż, 123 to 123, po co to testować ...
• x- ok, więc to nas martwi. Dopiero teraz mam kontekst.
• Wróć do ponownego rozważenia 123i dlaczego x jest do niego porównywany.

Kiedy widzę x == 123parsowanie mentalne to:

• x- Zapewnia kontekst, wiem o czym jest warunek. Mogę zignorować resztę. W oparciu o poprzedni przepływ mam dobry pomysł, dlaczego i co ma nadejść (i zdziwię się, jeśli będzie inaczej).
• == - Tak myślałem.
• 123 - Tak.

Zakłócenie jest niewielkie (w prostym przykładzie), ale zawsze to zauważam.

Stawianie wartości na pierwszym miejscu może być dobrym pomysłem, jeśli chcesz na nią zwrócić uwagę, np if (LAUNCH_NUKES == cmd). Zwykle nie taka jest intencja.

Szkodliwy? Nie. Działa tak czy inaczej.

Zła praktyka? W najlepszym razie dyskusyjne. To proste programowanie obronne.

Czy warto się przespać? Nie

To jest po prostu flaimbait.

Nie, to nie wyrządza więcej szkody niż pożytku. Prosty.

Więcej słów?

Argument kompilatora? Ehm, może, może - nie pokładaj zbytniej wiary w komplementa, aby cię ocalić od siebie.

„Nie należy zapominać” - dobrze duh - no oczywiście, że nie powinno tymczasem jestem zmęczony, byłem kodowania cały dzień musiałam korzystać z dwóch różnych języków, a czasem, po prostu czasami istota ludzka robię błąd.

Istota tego rodzaju zachowania polega na tym, że jest defensywny, nie ma go, ponieważ spodziewasz się popełnić więcej błędów niż masz ubezpieczenie, ponieważ spodziewasz się katastrofy ... ale jeśli zrobisz, to miło jest być chronionym.

Ciężkie do przeczytania? Narzekasz, że porządny programista powinien mieć == przewodowy (co czyni wszelkiego rodzaju złe założenia), ale że sam ten sam porządny programista nie może odczytać wartości 0 ==?

Nie szkodzi, ma potencjalne korzyści, głupie pytanie, pozwól innym to zrobić, jeśli chcą i idź dalej.

Nie nazwałbym tego krzywdą, ale jest to wstrętne. Więc nie, nie powiedziałbym, że tak.

Nigdy nie czułem, że całe „a jeśli zapomnę = =?” kiedykolwiek naprawdę miał dużą wagę. Tak, możesz zrobić literówkę, ale wszyscy robimy literówki, głupotą wydaje się zmiana całego stylu kodowania, ponieważ boisz się popełnić błąd. Dlaczego nie sprawić, by wszystkie zmienne i funkcje były pisane małymi literami bez żadnych znaków interpunkcyjnych, ponieważ możesz zapomnieć o pisaniu wielkich liter lub zapomnieć o podkreśleniu?

Niektórzy używają go, aby wyjaśnić dokładnie, co robi warunek. Na przykład:

Sposób 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Sposób 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

Niektórzy uważają, że drugi przykład jest bardziej zwięzły, lub odwrócenie argumentów ilustruje sens testu (warunkowy) przed samym testem.

W rzeczywistości tak naprawdę nie mam nic przeciwko. Mam swoje zwierzaki na punkcie stylu, a największym jest niekonsekwencja. Więc rób to w ten sam sposób, konsekwentnie i nie będę miał nic przeciwko czytaniu twojego kodu.

Wymieszaj to do momentu, w którym wygląda na to, że sześć różnych osób z własnym charakterystycznym stylem pracowało nad tym naraz, jestem trochę zirytowany.

Dla mnie to proste warunkowanie. Jako ktoś, kto nauczył się (w latach 90.) C i C ++, przyzwyczaiłem się do niego i nadal go używam, pomimo tego, że przyczyny są lekcji.

Kiedy jesteś „uwarunkowany”, aby spojrzeć na „stałą” po lewej stronie, staje się on drugą naturą.

Używam go również tylko do równoważności (lub równoważności zanegowanej), a nie do większej / mniejszej niż.

Całkowicie zgadzam się z odpowiedzią W / @ Wonko.

Jedynym przypadkiem, w którym uważam to za pomocne, jest to, że zmienna część if jest dość długa, a zobaczenie wartości ułatwia odczytanie kodu. Języki kropkowane w przestrzeni nazw mają najlepsze tego przykłady.

Na przykład coś, nad czym pracowałem przy jednokrotnym logowaniu, miało sytuację, w której mogłeś mieć dwie równoczesne sesje, jeśli wystąpiłby pewien rodzaj błędu i został odzyskany w określony sposób, więc muszę dodać moduł obsługi tego, który był w środku i jeśli wyglądał coś takiego:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

Wprawdzie w tym przykładzie istnieją inne sposoby, aby to zrobić, ale byłby to przypadek, w którym pierwsza wersja jest potencjalnie bardziej czytelna.

A jednak występują błędy. A czasem potrzebujesz przypisania w operatorze pętli, w którym możesz w przeciwnym razie sprawdzić równość, a przynajmniej standardową praktyką jest korzystanie z niego.

Trochę się z tym zgadzam. Porada, której podążyłem (prawdopodobnie z Code Complete), to zachować w porównaniach to, co powinno mieć niższą wartość po lewej stronie. Rozmawiałem o tym wcześniej z kolegą i pomyślał, że to trochę szalone, ale bardzo się do tego przyzwyczaiłem.

Powiedziałbym więc:

if ( 0 <= value )

Ale powiedziałbym również:

if ( value <= 100 )

Równość, którą zwykle sprawdzam za pomocą zmiennej po lewej, jest po prostu bardziej czytelna.