Czy powinienem używać nawiasów w instrukcjach logicznych, nawet jeśli nie jest to konieczne?

100

Powiedzmy, że mam warunek boolowski a AND b OR c AND di używam języka, w którym ANDprecedens jest wyższy niż w przypadku operacji OR. Mógłbym napisać ten wiersz kodu:

If (a AND b) OR (c AND d) Then ...

Ale tak naprawdę odpowiada to:

If a AND b OR c AND d Then ...

Czy są jakieś argumenty za lub przeciw dołączaniu obcych nawiasów? Czy praktyczne doświadczenie sugeruje, że warto je uwzględnić ze względu na czytelność? Czy może to znak, że deweloper musi naprawdę usiąść i nabrać pewności w podstawach swojego języka?

Jeff Bridgman
źródło
90
Mogę być leniwy, ale wolę mieć nawiasy w większości takich sytuacji w celu zapewnienia czytelności.
thorsten müller
6
Ja też. Mam tylko nadzieję, że robię to bardziej dla czytelności, a mniej, ponieważ jestem zbyt leniwy, aby stać się pewnym / kompetentnym w podstawach mojego języka.
Jeff Bridgman,
16
Dobre użycie nawiasów jest jak dobre użycie gramatyki. 2 * 3 + 2może być taki sam, (2 * 3) + 2ale drugi jest łatwiejszy do odczytania.
Reactgular
16
@Mateusz Być może jeśli masz słabą matematykę. W przypadku bardziej skomplikowanych przypadków użyj nawiasów. Ale dla oślepiająco oczywistych (BODMAS…) zmniejszają czytelność bardziej niż pomagają z powodu bałaganu.
Konrad Rudolph
3
To powiedziawszy, ten sam priorytet AND / OR obowiązuje w Basic, Python, SQL ... mam wrażenie, że jest to reguła w zdecydowanej większości współczesnych języków (choć nie wszystkie).
Tim Goodman,

Odpowiedzi:

117

Dobrzy programiści starają się pisać kod, który jest przejrzysty i poprawny . Nawiasy w warunkach warunkowych, nawet jeśli nie są ściśle wymagane, pomagają w obu przypadkach.

Jeśli chodzi o przejrzystość , pomyśl o nawiasach takich jak komentarze w kodzie: nie są one absolutnie konieczne, a teoretycznie kompetentny programista powinien być w stanie znaleźć kod bez nich. A jednak te wskazówki są niezwykle pomocne, ponieważ:

  • Ograniczają pracę wymaganą do zrozumienia kodu.
  • Stanowią potwierdzenie zamiaru dewelopera.

Ponadto dodatkowe nawiasy, podobnie jak wcięcia, białe znaki i inne standardy stylu, pomagają wizualnie uporządkować kod w logiczny sposób.

Jeśli chodzi o poprawność , warunki bez nawiasów są receptą na głupie błędy. Kiedy się zdarzają, mogą być błędami, które są trudne do znalezienia - ponieważ często niepoprawny stan będzie się zachowywał przez większość czasu i tylko czasami zawiedzie.

I nawet jeśli dobrze to zrobisz, następna osoba, która popracuje nad twoim kodem, może tego nie zrobić, dodając błędy do wyrażenia lub niezrozumienie logiki, a tym samym dodając błędy w innym miejscu (jak słusznie podkreśla LarsH).

Zawsze używam nawiasów do wyrażeń, które łączą się andi or(a także do operacji arytmetycznych z podobnymi priorytetami).

użytkownik82096
źródło
3
Chociaż słyszałem, że komentarze to przeprosiny (za zły / trudny do odczytania kod) ... istnieje duża szansa, że ​​mógłbyś go lepiej napisać. Wydaje mi się, że można powiedzieć coś podobnego o nawiasach.
Jeff Bridgman,
6
Innym aspektem poprawności jest zachowanie go przez zmiany: chociaż pierwotny programista może uzyskać pierwszeństwo bez nawiasów, gdy po raz pierwszy pisze kod z myślą o celu i kontekście, on (lub inny) pojawia się później i nie pamięta wszystkiego szczegóły mogą go zepsuć, gdy dodadzą więcej wyrażeń do wyrażenia. (Było to już w większości implikowane, ale czułem, że warto to podkreślić.)
LarsH
1
@LarsH, dzięki, dodałem to wprost do odpowiedzi.
8
+1 „Zapewniają potwierdzenie woli dewelopera”. - każdy programista (OK, może nie wszyscy, ale wszyscy, którzy tu mieszkają ...) może ustalić, co kompilator zrobi z najbardziej złożoną logiką. Absolutnie nikt nie jest w stanie ustalić, co zamierzał pierwotny programista (w tym on sam) kilka tygodni później w przypadku czegokolwiek poza najprostszym .....
mattnz
2
Myślę, że @JeffBridgman odwoływał się do dość dobrze znanego stanowiska, że ​​„komentarze mogą czasem pachnieć kodem”. Np. Zobacz podsumowanie Jeffa Atwooda, które zawiera pytanie „Czy możesz zmienić kod, aby komentarze nie były wymagane?”. Twierdzę, że jeśli twój komentarz wyjaśnia, dlaczego twój kod jest tak cholernie nieintuicyjny, to z pewnością może to być wskazówka, że ​​coś jest nie tak. W takich momentach warto uprościć kod. Jednak całkowicie zgadzam się z twoją rzeczywistą odpowiedzią i przyjmuję nawiasy.
Daniel B
94

Nie ma znaczenia, czy jesteś pewny swojego języka. Bardziej liczy się znajomość języka n00b, który podąża za tobą.

Napisz swój kod w najczystszy i najbardziej jednoznaczny sposób. Dodatkowy nawias często pomaga (ale nie zawsze). Umieszczenie tylko jednego wyrażenia w wierszu często pomaga. Spójność w stylu kodowania często pomaga.

Jest coś takiego jak zbyt wiele nawiasów, ale jest to jedna z tych sytuacji, w których nie potrzebujesz porady - poznasz ją, gdy ją zobaczysz. W tym momencie refaktoryzuj kod, aby zmniejszyć złożoność instrukcji, zamiast usuwać nawiasy.

Dan Pichelman
źródło
72
Nie zapominaj, że nawet jeśli jesteś programistą solo, kiedy jesteś chory, zmęczony lub masz do czynienia z kodem, który napisałeś w zeszłym roku; twój poziom zrozumienia jest zredukowany do poziomu n00b.
Dan Neely,
30
There is such a thing as too many parenthesis- nie jesteś oczywiście lisper;)
Paul
18
To zła rada: nie pisz dla noobów. Spowoduje to obniżenie jakości kodu (znacznie), ponieważ nie można używać dobrze ugruntowanych idiomów, które wykraczają poza pierwsze dwa rozdziały książki dla początkujących.
Konrad Rudolph
10
@KonradRudolph: może tak, ale nie pisz dla jedynych facetów, którzy znają sztukę programowania komputerowego od deski do deski albo bądź przygotowany na debugowanie kodu i nie masz pojęcia, dlaczego zrobiłeś to w ten sposób . Kod jest odczytywany znacznie więcej niż jest napisany.
haylem
15
@dodgethesteamroller: Widziałem zbyt wielu kompetentnych / szanowanych programistów wprowadzających błędy pierwszeństwa (każdy ma teraz zły dzień), które pozostają niezauważone przez wieki. Dla dobrych programistów, którzy znają zasady pierwszeństwa, ryzyko niewykrycia błędów / literówek jest zbyt wysokie. Dla wszystkich innych ryzyko jest wyższe. Najlepsi programiści to programiści, którzy pamiętali reguły pierwszeństwa języka, ale zapomnieli o nich, ponieważ zwykle używają nawiasów do wszystkiego, co nieoczywiste.
Brendan
31

tak

Zawsze powinieneś używać nawiasów ... nie kontrolujesz kolejności pierwszeństwa ... programista kompilatora tak. Oto historia, która mi się przytrafiła na temat niestosowania nawiasów. Wpłynęło to na setki ludzi w okresie dwóch tygodni.

Prawdziwy powód świata

Odziedziczyłem aplikację z ramką główną. Któregoś dnia przestało działać. To jest to ... po prostu przestało.

Moim zadaniem było jak najszybsze działanie. Kod źródłowy nie był modyfikowany przez dwa lata, ale nagle przestał. Próbowałem skompilować kod, który zepsuł się na linii XX. Spojrzałem na linię XX i nie mogłem powiedzieć, co spowodowałoby przerwanie linii XX. Poprosiłem o szczegółowe specyfikacje dla tej aplikacji i nie było żadnych. Linia XX nie była winowajcą.

Wydrukowałem kod i zacząłem go przeglądać od góry do dołu. Zacząłem tworzyć schemat blokowy tego, co się działo. Kod był tak zawiły, że ledwie mogłem go zrozumieć. Zrezygnowałem z próbowania schematu blokowego. Bałam się dokonywać zmian, nie wiedząc, jak ta zmiana wpłynie na resztę procesu, zwłaszcza, że ​​nie miałem szczegółowych informacji o tym, co zrobiła aplikacja ani gdzie była w łańcuchu zależności.

Postanowiłem więc zacząć od górnej części kodu źródłowego i dodać białe znaki i hamulce linii, aby kod był bardziej czytelny. Zauważyłem, że w niektórych przypadkach występowały warunki, które się łączyły ANDi ORnie można było jednoznacznie odróżnić, które dane były ANDedytowane i jakie dane były ORedytowane. Zacząłem więc umieszczać nawiasy wokół warunków ANDi ORwarunków, aby były bardziej czytelne.

Gdy powoli przesuwałem się w dół, aby go wyczyścić, okresowo zapisywałem swoją pracę. W pewnym momencie próbowałem skompilować kod i wydarzyło się coś dziwnego. Błąd przeskoczył, przekroczył pierwotny wiersz kodu i był teraz niższy. Więc kontynuowałem, rozróżniając ANDi ORwarunki za pomocą parens. Kiedy skończyłem sprzątać, zadziałało. Domyśl.

Następnie postanowiłem odwiedzić sklep operacyjny i zapytać, czy ostatnio zainstalowali jakieś nowe komponenty na ramie głównej. Powiedzieli tak, niedawno zaktualizowaliśmy kompilator. Hmmmm

Okazuje się, że stary kompilator niezależnie oceniał wyrażenie od lewej do prawej. Nowa wersja kompilatora oceniała również wyrażenia od lewej do prawej, ale niejednoznaczny kod, co oznacza niejasną kombinację ANDi ORnie można było rozwiązać.

Czego się nauczyłem z tego ... ZAWSZE, ZAWSZE, ZAWSZE używajcie parenów do oddzielonych ANDwarunków i ORwarunków, kiedy są one używane w połączeniu ze sobą.

Uproszczony przykład

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...(kod zaśmiecony kilkoma z nich)

To jest uproszczona wersja tego, co napotkałem. Były też inne warunki ze złożonymi wyrażeniami logicznymi.

Pamiętam, że postanowiłem to:
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...



Nie mogłem go przepisać, ponieważ nie było specyfikacji. Pierwotnego autora już dawno nie było. Pamiętam intensywną presję. Cały statek towarowy pozostawiono w porcie i nie można go było rozładować, ponieważ ten mały program nie działał. Bez ostrzeżenia. Brak zmian w kodzie źródłowym. Przyszło mi do głowy, aby zapytać Operacje sieciowe, czy coś zmodyfikowały po tym, jak zauważyłem, że dodanie parens zmieniło błędy.

Michael Riley - AKA Gunny
źródło
22
To wydaje się lepszą ilustracją tego, dlaczego ważne jest, aby mieć dobry kompilator.
ruakh
6
@CapeCodGunny: Jestem pewien, że nie. Problem polega jednak na tym, że miałeś złego dostawcę kompilatora, który dokonał przełomowej zmiany. Nie rozumiem, jak nauczyłeś się lekcji „ZAWSZE, ZAWSZE, ZAWSZE” omijać ten problem, nawet przy korzystaniu z lepszych kompilatorów.
ruakh
5
@ruakh - Nie, sprzedawca po prostu zmienił parser kodu. Jestem oldschoolowy, nie polegam na mojej zdolności do zapamiętywania każdego systemu, w którym kodowałem lub byłem zaangażowany. Bez dokumentacji wystarczy kod źródłowy. Gdy kod źródłowy jest trudny do odczytania i zastosowania, tworzy to wyjątkowo stresującą sytuację. Programiści, którzy nie używają białych znaków, prawdopodobnie nigdy nie mieli do czynienia z sytuacją taką jak ta, z którą się spotkałem. Dowiedziałem się również, że bardziej sensowne jest pisanie kodu takiego jak: Patrz Dick; Zobacz Jane; Zobacz Dick I Jane; Proste stwierdzenia, które są łatwe do odczytania ... skomentuj ... i obserwuj.
Michael Riley - AKA Gunny
2
Świetna historia, ale zgadzam się, że nie należy używać nawiasów. i / lub pierwszeństwo jest prawie uniwersalne i dotyczy najmniej prawdopodobnej zmiany, o której można pomyśleć. Jeśli nie możesz polegać na spójnym zachowaniu w przypadku takiej standardowej, podstawowej operacji, Twój kompilator jest śmieciem i nie ma znaczenia, co robisz. Twoja historia jest w 100% problemem kompilatora, a 0% problemem kodu. Zwłaszcza, że ​​domyślnym zachowaniem była prosta ocena od lewej do prawej - kolejność zawsze byłaby jasna, więc dlaczego ktokolwiek miałby używać nawiasów?
7
Myślę, że po obu stronach wyciągnięto wnioski ... O wiele lepiej jest używać nawiasów, szczególnie gdy alternatywa polega na nieudokumentowanym zachowaniu kompilatora w odniesieniu do niejednoznacznego kodu . A jeśli programista nie wie, które wyrażenia są niejednoznaczne, lepiej użyj parens. Z drugiej strony zmiana zachowania kompilatora jest niebezpieczna, ale przynajmniej rzucił błąd w przypadkach, w których zachowanie się zmieniło. Byłoby gorzej, gdyby kompilator nie zgłosił błędu, ale zaczął kompilować inaczej. Błąd chronił Cię przed niezauważonymi błędami.
LarsH
18

Tak, jeśli są mieszane „i” i „lub”.

Również dobrym pomysłem jest (), co jest logicznie jednym sprawdzeniem.

Chociaż najlepiej jest używać dobrze nazwanych funkcji predykatów i eksmitować większość kontroli i warunków, pozostawiając je proste i czytelne.

Balog Pal
źródło
6
To prawda, że ​​istnieje bardzo duża szansa, że a AND bprawdopodobnie należy ją zastąpić funkcją lub wstępnie obliczoną wartością boolen, która ma bardziej opisową nazwę.
Jeff Bridgman,
14

Nawiasy są semantycznie redundantne, więc kompilator nie dba o to, ale to czerwony śledź - prawdziwą troską jest czytelność i zrozumienie programisty.

Zajmę tutaj radykalne stanowisko i udzielę serdecznego „nie” nawiasom w środku a AND b OR c AND d. Każdy programista powinien na pamięć wiedzieć, że pierwszeństwo w wyrażeniach boolowskich NIE JEST> I> LUB , podobnie jak pamiętanie Proszę wybacz mojej drogiej cioci Sally wyrażeń algebraicznych. Nadmiarowa interpunkcja po prostu dodaje bałaganu wizualnego przez większość czasu w kodzie, bez korzyści dla czytelności programisty.

Ponadto, jeśli zawsze używasz nawiasów w wyrażeniach logicznych i algebraicznych, rezygnujesz z możliwości używania ich jako markera „dzieje się tutaj coś trudnego - uważaj!” Oznacza to, że w przypadkach, w których chcesz zastąpić domyślny priorytet i dokonać oceny dodania przed pomnożeniem lub LUB przed AND, nawiasy są ładną czerwoną flagą dla następnego programisty. Zbyt wiele z nich korzysta, gdy nie są potrzebne, a Ty stajesz się Chłopcem, Który Płakał Wilkiem.

Zrobiłbym wyjątek dla wszystkiego poza sferą algebry (boolowskiej lub nie), takiej jak wyrażenia wskaźnikowe w C, gdzie wszystko bardziej skomplikowane niż standardowe idiomy, takie jak *p++lub p = p->nextprawdopodobnie powinny być nawiasowane, aby utrzymać dereferencje i arytmetykę prosto. I oczywiście nic z tego nie dotyczy języków takich jak Lisp, Forth lub Smalltalk, które używają jakiegoś rodzaju polskiego zapisu do wyrażeń; ale w przypadku większości głównych języków logiczne i arytmetyczne pierwszeństwo jest całkowicie ustandaryzowane.

dodgethesteamroller
źródło
1
+1, nawiasy dla przejrzystości są w porządku, ale ANDvs ORjest dość prostym przypadkiem, o którym chciałbym wiedzieć inni deweloperzy z mojego zespołu. Martwię się, że czasami „używanie nawiasów dla jasności” to tak naprawdę „używanie nawiasów, więc nigdy nie muszę się martwić, aby nauczyć się pierwszeństwa”.
Tim Goodman
1
We wszystkich językach, z którymi pracuję regularnie to .memberzanim operatorzy unarne, unarne przed operatorów binarnych, *a /przed +i -przed <a >i ==przed &&przed ||przed zadaniem. Zasady te są łatwe do zapamiętania, ponieważ pasuje do mojego „zdrowego rozsądku” o tym, jak zwykle stosowane są operatorzy (np, nie dałoby ==większy priorytet niż +lub 1 + 1 == 2przestaje działać), a obejmują one 95% pytań pierwszeństwa Musiałbym .
Tim Goodman
4
@TimGoodman Tak, dokładnie w obu przypadkach. Inni respondenci uważają, że jest to pytanie czarne lub białe - albo używaj nawiasów przez cały czas, bez wyjątków, albo lataj niedbale przy siedzeniu spodni przez morze arbitralnych i niemożliwych do zapamiętania zasad, a twój kod się gotuje z potencjalnymi trudnymi do wykrycia błędami. (Mieszane metafory bardzo celowe.) Oczywiście właściwą drogą jest umiar; przejrzystość kodu jest ważna, ale dobrze zna się na twoich narzędziach i powinieneś być w stanie spodziewać się pewnego minimalnego zrozumienia zasad programowania i CS od swoich kolegów z drużyny.
dodgethesteamroller
8

Jak to widze:

TAK Plusy:

  • Kolejność operacji jest wyraźna.
  • Chroni przed przyszłymi programistami, którzy nie rozumieją kolejności operacji.

TAK Wady:

  • Może to spowodować zaśmiecenie trudnego do odczytania kodu

NIE Plusy:

  • ?

NIE Wady:

  • Kolejność operacji jest niejawna
  • Kod jest trudniejszy do utrzymania dla programistów bez dobrego zrozumienia kolejności operacji.
MetaFight
źródło
Dobrze powiedziane, choć myślę, że „Może to spowodować zaśmiecenie trudnego do odczytania kodu” jest raczej subiektywne.
FrustratedWithFormsDesigner
2
W jaki sposób wyraźne określenie semantyki kodu utrudnia czytanie?
Mason Wheeler,
1
Zgadzam się z innymi, kwestionując twoje „tak minusy”. Myślę, że prawie zawsze jest odwrotnie.
@Frustrated Tak subiektywny jak twierdzenie przeciwne. Znaczy, wcale nie tak naprawdę. Po prostu trudne do zmierzenia.
Konrad Rudolph
1
@MasonWheeler: Chociaż zgadzam się, że wyraźne pareny są bardzo ważne w wielu przypadkach, widzę, jak można przesadzić, czyniąc semantykę wyraźną. Uważam, że jest 3 * a^2 + 2 * b^2łatwiejszy do odczytania (3 * (a^2)) + (2 * (b^2)), ponieważ format i pierwszeństwo są znane i standardowe. Podobnie, możesz (być ekstremalnie) zabronić używania funkcji i makr (lub kompilatorów!), Aby uczynić semantykę twojego kodu bardziej wyraźnym. Oczywiście nie jestem zwolennikiem tego, ale mam nadzieję odpowiedzieć na twoje pytanie, dlaczego istnieją ograniczenia (równowaga) w wyrażaniu rzeczy.
LarsH
3

Czy są jakieś argumenty za lub przeciw dołączaniu obcych nawiasów? Czy praktyczne doświadczenie sugeruje, że warto je uwzględnić ze względu na czytelność? Czy może to znak, że deweloper musi naprawdę usiąść i nabrać pewności w podstawach swojego języka?

Jeśli nikt inny nie będzie musiał ponownie patrzeć na mój kod, nie sądzę, żebym się tym przejmował.

Ale z mojego doświadczenia:

  • Od czasu do czasu patrzę na swój kod (czasem lata po jego napisaniu)
  • Inni czasem patrzą na mój kod
    • Lub nawet trzeba go rozwinąć / naprawić!
  • Ani ja, ani inni nie pamiętamy dokładnie, o czym myślałem pisząc to
  • Pisanie tajemniczego kodu „minimalizuj liczbę znaków” szkodzi czytelności

Prawie zawsze to robię, ponieważ ufam, że potrafię szybko czytać i nie popełniać drobnych błędów dużo więcej przy użyciu parens niż nic innego.

W twoim przypadku prawie na pewno zrobiłbym coś takiego:

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

Tak, to więcej kodu. Tak, mogę zamiast tego robić fantazyjne operatory bool. Nie, nie podoba mi się ta szansa, że ​​w przyszłości, gdy przeglądam kod ponad 1 rok, źle odczytałem operatorów fantazyjnych bool. Co jeśli pisałbym kod w języku, który miał inny priorytet ORAZ / LUB i musiałbym wrócić, aby to naprawić? Czy mam zamiar powiedzieć: „aha! Pamiętam tę sprytną rzecz, którą zrobiłem! Nie musiałem uwzględniać parens, kiedy pisałem ten ostatni rok, dobrze, że teraz pamiętam!” jeśli tak się stanie (lub gorzej, ktoś inny, kto nie był świadomy tego sprytu lub został wrzucony w sytuację typu „napraw jak najszybciej”)?

Rozdzielenie za pomocą () znacznie ułatwia szybkie przeglądanie i zrozumienie później ...

kraina krańca
źródło
7
Jeśli masz zamiar to zrobić, dlaczego nie ab = a AND b?
Eric
1
Być może dlatego ab, że pozostanie niezmieniony, jeśli nie a AND b.
Armali,
3

Ogólna sprawa

W języku C # mnożenie i dzielenie ma pierwszeństwo przed dodawaniem i odejmowaniem.

Mimo to StyleCop, narzędzie, które wymusza wspólny styl w bazie kodu z dodatkowym celem, aby zmniejszyć ryzyko wprowadzenia błędów przez kod, które mogą nie być wystarczająco jasne, ma regułę SA1407 . Ta reguła wyświetli ostrzeżenie z fragmentem kodu takim jak ten:

var a = 1 + 2 * 3;

Oczywiste jest, że wynik jest , ale 7nie 9, ale StyleCop sugeruje umieszczenie nawiasu:

var a = 1 + (2 * 3);

Twoja szczególna sprawa

W twoim konkretnym przypadku istnieje pierwszeństwo AND w stosunku do OR w konkretnym języku, którego używasz.

Nie tak zachowuje się każdy język. Wielu innych traktuje AND i OR równo.

Jako programista, który pracuje głównie z C #, kiedy zobaczyłem twoje pytanie po raz pierwszy i przeczytałem fragment kodu bez czytania tego, co napisałeś wcześniej, moją pierwszą pokusą było skomentowanie, że te dwa wyrażenia nie są takie same. Mam nadzieję, że przeczytałem całe pytanie całkowicie przed komentowaniem.

Ta szczególność i ryzyko, że niektórzy programiści mogą wierzyć, że AND i OR mają ten sam priorytet, sprawia, że ​​jeszcze ważniejsze jest dodanie nawiasu.

Nie pisz kodu, aby pokazać, że jesteś mądry. Napisz kod w celu zapewnienia czytelności, w tym przez osoby, które mogą nie znać każdego aspektu języka.

Arseni Mourzenko
źródło
1
„Jest to bardzo rzadkie”: Według Stroustrup 2013, C ++ 11 wydaje się mieć inny priorytet dla AND i OR (s. 257). To samo dotyczy Pythona: docs.python.org/2/reference/expressions.html
Dirk
10
Re: „Każdy język, który znam, traktuje ORAZ i LUB równo”. Wątpię, czy to prawda. Jeżeli to jest prawda, to nie wiem, każdy z dziesięciu najpopularniejszych językach (C, Java, C ++, PHP, JavaScript, Python, C #, Perl, SQL, Ruby), i nie są w stanie do komentowania co jest „niezwykłe”, a co dopiero „bardzo rzadkie”.
ruakh
1
Zgadzam się z ruakh i szukałem C ++ 11, Pythona, Matlaba i Javy.
Dirk
3
Języki, w których AND i OR są operatorami binarnymi, i które nie traktują AND jako mające wyższy priorytet niż OR, są bzdurami, których autorami są bzdury informatyczne. Wynika to z notacji logicznej. Witaj, czy „suma produktów” nic nie znaczy? Istnieje nawet notacja boolowska, która używa mnożenia (zestawienia czynników) dla AND, a symbol + dla OR.
Kaz
3
@ruakh Właśnie przedstawiłeś mi swój punkt widzenia. Ponieważ istnieje kilka patologicznych przypadków skrajnych, nie oznacza to, że nie powinieneś uczyć się standardowego logicznego pierwszeństwa i zakładać, że ma ono zastosowanie, dopóki nie zostanie udowodnione inaczej. Nie mówimy tutaj o arbitralnych decyzjach projektowych; Algebra boolowska została wynaleziona na długo przed komputerami. Pokaż mi także specyfikację Pascala, o której mówisz. Tu i tutaj pokaż ORAZ przed OR.
dodgethesteamroller
1

Jak wszyscy mówili, używaj nawiasów za każdym razem, gdy sprawia, że ​​wyrażenie jest bardziej czytelne. Jeśli jednak wyrażenie jest skomplikowane, radzę wprowadzić nowe funkcje dla podwyrażeń .

Honza Brabec
źródło
0

Czy może to znak, że deweloper musi naprawdę usiąść i nabrać pewności w podstawach swojego języka?

Jeśli ściśle używasz języka w liczbie pojedynczej, być może. Teraz weź wszystkie języki, które znasz, od najmłodszych do najbardziej nowoczesnych, od skompilowanych, przez skrypty, przez SQL, aż po własną DSL, którą wymyśliłeś w zeszłym miesiącu.

Czy pamiętasz dokładne zasady pierwszeństwa dla każdego z tych języków, nie patrząc?

Bezpieczne
źródło
1
I jak zauważył @Cape Cod Gunny powyżej, nawet jeśli uważasz, że znasz język zimno, kompilator / czas działania może się zmienić pod tobą.
Jordan
0

„Czy powinienem używać nawiasów w logicznych instrukcjach, nawet jeśli nie jest to konieczne”.

Tak, ponieważ dwie osoby uznają je za pomocne:

  • Następny programista, którego wiedza, kompetencje lub styl mogą być inne

  • Przyszłość, która wróci do tego kodu w późniejszym terminie!

Michael Durrant
źródło
-1

Złożone warunki warunkowe to „algebra boolowska”, którą piszesz na kilka sposobów, dzięki czemu wygląda ona prawie dokładnie tak jak algebra, a na pewno używasz parens do algebry , prawda?

Naprawdę przydatne są zasady negacji:

!(A || B) <=> !A && !B
!(A && B) <=> !A || !B

Lub w nieco jaśniejszym formacie:

!(A + B) <=> !A * !B
!(A * B) <=> !A + !B

co tak naprawdę jest po prostu algebrą, gdy jest napisane jako:

-1*(A + B) = -A + -B
-1*(A * B) = -A * -B

Ale możemy również zastosować myślenie w zakresie algebraicznego uproszczenia i ekspansji:

(A && B) || (C && D) => 
((A && B) || C) && ((A && B) || D) => 
(AC && BC) && (AD && BD) =>
AC && BC && AD && BD

chociaż w kodzie musisz napisać:

(A||C) && (B||C) && (A||D) && (B||D)

lub w nieco jaśniejszym formacie:

(A + B) * (C + D) => 
((A + B) * C) + ((A + B) * D) => 
(AC + BC) + (AD + BD) =>
AC + BC + AD + BD

Zasadniczo, warunek jest nadal tylko wyrażeniem algebraicznym, a poprzez wyraźne użycie nawiasów można łatwiej zastosować różne reguły algebraiczne, które już znasz do wyrażenia, w tym starą koncepcję „uproszczenia lub rozwinięcia tej formuły”.

Narfanator
źródło
2
Nie jestem pewien, czy faktycznie odpowiadasz na pytanie, ponieważ prowadzisz swoją odpowiedź z założeniem, że niekoniecznie jest to prawda. Czy użyłbym nawiasów do algebry? Nie cały czas. Jeśli to pomaga w czytelności, to na pewno, ale inni już to wyrazili. A rozszerzenie algebry matematycznej na inne formy nie ma dokładnie takiej samej relacji z programowaniem - co jeśli sprawdzasz status kilku wartości ciągu?
Derek
Jeśli odpowiednia algebra boolowska jest wystarczająco skomplikowana, aby uzasadnić pareny, twój warunkowy prawdopodobnie powinien używać parens. Jeśli jest to wystarczająco proste, aby nie uzasadniać parens, albo nie musisz, albo nie powinieneś. Tak czy inaczej, myślenie o tym jak o matematycznym wyrażeniu prawdopodobnie wyjaśnia problem.
Narfanator,
Moje powyższe przykłady wykorzystują dwa i cztery booleany. Jeśli sprawdzasz status dwóch lub więcej wartości ciągów, zostanie to odwzorowane. Każde sprawdzenie odpowiada jednej zmiennej boolowskiej; bez względu na to, czy ta kontrola jest liczbą całkowitą, czy ciągiem równości; włączenie ciągu, tablicy lub skrótu; samo złożone wyrażenie ... Nie ma znaczenia; liczy się tylko to, że w swoim wyrażeniu masz więcej niż jeden pomiar wartości prawda / fałsz.
Narfanator,
2
Wystarczy nitpicking, ale !(A + B) <=> !A + !Bi -1*(A + B) = -A + -Bnie powinno operator zostały odwrócone od +celu *w drugiej wypowiedzi?
Jeff Bridgman,
-1

Użyję nawiasów, nawet jeśli jest to opcjonalne, dlaczego, ponieważ pomaga to lepiej zrozumieć dla wszystkich, zarówno dla tego, kto pisze kod, jak i dla tego, który jest gotowy do zobaczenia tego kodu. W twoim przypadku nawet operatorzy logiczni mają pierwszeństwo, może na początku działać dobrze, ale nie możemy powiedzieć, że pomoże ci to w każdym przypadku. więc wolę nawias użytkownika w każdych warunkach, które mogą wymagać lub opcjonalnie.

singa selva sankar
źródło
-1

Tak. Powinieneś używać w każdym przypadku, gdy uważasz, że kod będzie bardziej przejrzysty. Pamiętaj, że twój kod powinien być wystarczająco jasny, aby inni mogli zrozumieć bez czytania twoich komentarzy wewnątrz kodu. Dobrą praktyką jest używanie nawiasów i nawiasów klamrowych. Pamiętaj również, że może to zależeć od konkretnej praktyki Twojej firmy / zespołu. Po prostu zachowaj jedno podejście i nie mieszaj.

DeveloperArnab
źródło