Dovrei usare le parentesi nelle istruzioni logiche anche dove non sono necessarie?

Diciamo che ho una condizione booleana a AND b OR c AND de sto usando una lingua in cui il precedente ANDè un ordine di funzionamento superiore OR. Potrei scrivere questa riga di codice:

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

Ma in realtà, questo equivale a:

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

Ci sono argomenti a favore o contro tra cui le parentesi estranee? L'esperienza pratica suggerisce che vale la pena includerli per la leggibilità? O è un segno che uno sviluppatore deve davvero sedersi e diventare fiducioso nelle basi della loro lingua?

I buoni sviluppatori si sforzano di scrivere codice che sia chiaro e corretto . Le parentesi nei condizionali, anche se non sono strettamente necessarie, aiutano con entrambi.

Per quanto riguarda la chiarezza , pensa alle parentesi come ai commenti nel codice: non sono strettamente necessari e in teoria uno sviluppatore competente dovrebbe essere in grado di capire il codice senza di loro. Eppure, questi suggerimenti sono estremamente utili, perché:

• Riducono il lavoro richiesto per comprendere il codice.
• Forniscono la conferma dell'intenzione dello sviluppatore.

Inoltre, parentesi extra, proprio come rientri, spazi bianchi e altri standard di stile, aiutano a organizzare visivamente il codice in modo logico.

Per quanto riguarda la correttezza , le condizioni senza parentesi sono una ricetta per errori sciocchi. Quando accadono, possono essere bug difficili da trovare, perché spesso una condizione errata si comporterà correttamente per la maggior parte del tempo e solo occasionalmente fallirà.

E anche se hai capito bene, la persona successiva a lavorare sul tuo codice potrebbe non farlo, aggiungendo errori all'espressione o fraintendendo la tua logica e quindi aggiungendo errori altrove (come giustamente sottolinea LarsH).

Uso sempre le parentesi per le espressioni che combinano ande or(e anche per le operazioni aritmetiche con problemi di precedenza simili).

Poco importa se sei sicuro della tua padronanza della lingua. Ciò che conta di più è la comprensione del linguaggio dell'n00b che ti segue.

Scrivi il tuo codice nel modo più chiaro e inequivocabile possibile. Le parentesi extra spesso (ma non sempre) aiutano. Mettere solo una frase su una riga spesso aiuta. La coerenza nello stile di programmazione spesso aiuta.

Esistono troppe parentesi, ma è una di quelle situazioni in cui non avrai bisogno di consigli: lo saprai quando la vedrai. A quel punto refactoring il codice per ridurre la complessità dell'istruzione anziché rimuovere la parentesi.

sì

Dovresti sempre usare le parentesi ... non controlli l'ordine di precedenza ... fa lo sviluppatore del compilatore. Ecco una storia che mi è successa sul non uso delle parentesi. Ciò ha interessato centinaia di persone in un periodo di due settimane.

La ragione del mondo reale

Ho ereditato un'applicazione del frame principale. Un giorno, di punto in bianco, ha smesso di funzionare. È tutto ... ma è appena finito.

Il mio compito era farlo funzionare il più velocemente possibile. Il codice sorgente non era stato modificato per due anni, ma all'improvviso si è fermato. Ho provato a compilare il codice e si è rotto sulla linea XX. Ho guardato la linea XX e non riuscivo a capire cosa avrebbe interrotto la linea XX. Ho chiesto le specifiche dettagliate per questa applicazione e non ce ne sono state. La linea XX non era il colpevole.

Ho stampato il codice e ho iniziato a esaminarlo dall'alto verso il basso. Ho iniziato a creare un diagramma di flusso di ciò che stava succedendo. Il codice era così contorto che non riuscivo nemmeno a capirlo. Ho rinunciato a provare a disegnarlo. Avevo paura di apportare modifiche senza sapere come avrebbe influito sul resto del processo, soprattutto perché non avevo dettagli su cosa facesse l'applicazione o su dove si trovasse nella catena delle dipendenze.

Quindi, ho deciso di iniziare nella parte superiore del codice sorgente e aggiungere whitespce e freni di linea per rendere il codice più leggibile. Ho notato, in alcuni casi, che c'erano delle condizioni che si combinavano ANDe ORche non era chiaramente distinguibile tra quali dati venivano modificati ANDe quali dati venivano modificati OR. Così ho iniziato a mettere tra parentesi le condizioni ANDe ORper renderle più leggibili.

Mentre procedevo lentamente pulendola, salvavo periodicamente il mio lavoro. A un certo punto ho provato a compilare il codice e una cosa strana è accaduta. L'errore era passato oltre la riga di codice originale e ora era più in basso. Così ho continuato, speparando le condizioni ANDe ORcon le parentesi. Quando ho finito di pulirlo ha funzionato. Vai a capire.

Ho quindi deciso di visitare il negozio operativo e chiedere loro se avevano recentemente installato nuovi componenti sul telaio principale. Hanno detto di sì, abbiamo recentemente aggiornato il compilatore. Hmmmm.

Si scopre che il vecchio compilatore ha valutato l'espressione da sinistra a destra, indipendentemente. La nuova versione del compilatore ha anche valutato le espressioni da sinistra a destra ma il codice ambiguo, il che significa che la combinazione poco chiara di ANDe ORnon poteva essere risolta.

Lezione che ho imparato da questo ... SEMPRE, SEMPRE, SEMPRE usare i genitori per separare le ANDcondizioni e le ORcondizioni quando vengono usati in congiunzione tra loro.

Esempio semplificato

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...(codice disseminato di molti di questi)

Questa è una versione semplificata di ciò che ho incontrato. Vi erano anche altre condizioni con le dichiarazioni logiche booleane composte.

Ricordo di averlo insegnato a:
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...

Non ho potuto riscriverlo perché non c'erano specifiche. L'autore originale era scomparso da tempo. Ricordo un'intensa pressione. Un'intera nave mercantile rimase bloccata in porto e non poté essere scaricata perché questo piccolo programma non funzionava. Nessun avvertimento Nessuna modifica al codice sorgente. Mi è venuto in mente di chiedere alle Operazioni di rete se hanno modificato qualcosa dopo che ho notato che l'aggiunta di parentesi ha spostato gli errori.

Sì, se ci sono misti "e" e "o".

Anche una buona idea di () cosa è logicamente un controllo.

Anche se la cosa migliore è usare funzioni predicate ben denominate e sfrattare la maggior parte dei controlli e delle condizioni lì, lasciando se semplice e leggibile.

Le parentesi sono semanticamente ridondanti, quindi al compilatore non importa, ma si tratta di un'aringa rossa: la vera preoccupazione è la leggibilità e la comprensione del programmatore.

Prenderò la posizione radicale qui e darò un "no" alle parentesi a AND b OR c AND d. Ogni programmatore dovrebbe sapere a memoria che la precedenza nelle espressioni booleane NON è AND> E> OR , proprio come ricordare Please Excuse My Dear Aunt Sally per le espressioni algebriche. La punteggiatura ridondante aggiunge solo disordine visivo la maggior parte delle volte nel codice senza alcun vantaggio nella leggibilità del programmatore.

Inoltre, se usi sempre le parentesi nelle espressioni logiche e algebriche, allora rinunci alla possibilità di usarle come marker per "qualcosa di complicato sta accadendo qui - guarda fuori!" Cioè, nei casi in cui si desidera sovrascrivere la precedenza predefinita e fare valutare l'aggiunta prima della moltiplicazione, o OR prima di AND, le parentesi sono una bella bandiera rossa per il programmatore successivo. Troppo uso di loro quando non sono necessari, e tu diventi il ​​ragazzo che piangeva lupo.

Vorrei fare un'eccezione per qualsiasi cosa al di fuori del regno dell'algebra (booleana o no), come le espressioni puntatore in C, dove qualcosa di più complicato degli idiomi standard come *p++o p = p->nextprobabilmente dovrebbe essere tra parentesi per mantenere il dereferenziamento e l'aritmetica. E, naturalmente, nulla di tutto ciò si applica a lingue come Lisp, Forth o Smalltalk che usano una qualche forma di notazione polacca per le espressioni; ma per la maggior parte dei linguaggi tradizionali, la precedenza logica e aritmetica sono totalmente standardizzate.

Per come la vedo:

SÌ Pro:

• L'ordine delle operazioni è esplicito.
• Ti protegge dai futuri sviluppatori che non comprendono l'ordine delle operazioni.

SÌ Contro:

• Può risultare in codice ingombrante, difficile da leggere

NO Pro:

• ?

NO contro:

• L'ordine delle operazioni è implicito
• Il codice è meno gestibile per gli sviluppatori senza una buona comprensione dell'ordine delle operazioni.

Ci sono argomenti a favore o contro tra cui le parentesi estranee? L'esperienza pratica suggerisce che vale la pena includerli per la leggibilità? O è un segno che uno sviluppatore deve davvero sedersi e diventare fiducioso nelle basi della loro lingua?

Se nessun altro dovesse mai rivedere il mio codice, non credo che mi importerebbe.

Ma, dalla mia esperienza:

• Guardo di nuovo il mio codice di tanto in tanto (a volte anni dopo averlo scritto)
• Altri a volte guardano il mio codice
  • O addirittura devi espanderlo / ripararlo!
• Né me stesso né l'altro ricordiamo esattamente cosa stavo pensando quando lo scrissi
• Scrivere codice criptico "minimizza il conteggio dei caratteri" danneggia la leggibilità

Lo faccio quasi sempre perché mi fido della mia capacità di leggere rapidamente e di non commettere piccoli errori molto più con i genitori che altro.

Nel tuo caso, farei quasi sicuramente qualcosa del tipo:

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

Sì, è più codice. Sì, invece posso fare fantastici operatori bool. No, non mi piace la possibilità di sfogliare il codice 1+ anni in futuro, fraintendo gli operatori di bool fantasia. E se stavo scrivendo codice in una lingua con precedenza AND / OR diversa e dovessi tornare indietro per risolvere il problema? Ho intenzione di dire "aha! Ricordo questa piccola cosa intelligente che ho fatto! Non ho dovuto includere le parentesi quando ho scritto l'anno scorso, buona cosa che ricordo adesso!" se ciò accade (o peggio, qualcun altro che non era a conoscenza di questa intelligenza o era stato gettato in una situazione di tipo "aggiusta al più presto")?

Separare con () rende molto più semplice scorrere rapidamente e capire in seguito ...

Caso generale

In C #, la moltiplicazione e la divisione hanno la precedenza su addizione e sottrazione.

Tuttavia, StyleCop, uno strumento che impone uno stile comune in tutta la base di codice con un ulteriore obiettivo per mitigare il rischio di bug introdotti dal codice che potrebbe non essere abbastanza chiaro, ha la regola SA1407 . Questa regola produrrà un avviso con un pezzo di codice come questo:

var a = 1 + 2 * 3;

È chiaro che il risultato è 7e non 9, ma comunque, StyleCop suggerisce di mettere tra parentesi:

var a = 1 + (2 * 3);

Il tuo caso particolare

Nel tuo caso particolare, esiste una precedenza di AND rispetto a OR nella lingua specifica che usi.

Non è così che si comportano tutte le lingue. Molti altri trattano allo stesso modo AND e OR.

Come sviluppatore che lavora principalmente con C #, quando ho visto la tua domanda per la prima volta e ho letto il pezzo di codice senza leggere quello che hai scritto prima, la mia prima tentazione è stata quella di commentare che le due espressioni non sono uguali. Spero di aver letto l'intera domanda prima di commentare.

Questa particolarità e il rischio che alcuni sviluppatori possano ritenere che AND e OR abbiano la stessa priorità rendono ancora più importante aggiungere parentesi.

Non scrivere codice con l'obiettivo di dimostrare che sei intelligente. Scrivi codice con un obiettivo di leggibilità, anche da parte di persone che potrebbero non avere familiarità con ogni aspetto del linguaggio.

Come tutti hanno detto, usa le parentesi ogni volta che rende l'espressione più leggibile. Tuttavia, se l'espressione è complicata, consiglierei di introdurre nuove funzioni per le sottoespressioni .

O è un segno che uno sviluppatore deve davvero sedersi e diventare fiducioso nelle basi della loro lingua?

Se usi rigorosamente la lingua al singolare, forse. Ora prendi tutte le lingue che conosci, dai vecchi ai più moderni, dalla compilazione allo scripting a SQL al tuo DSL che hai inventato il mese scorso.

Ti ricordi le regole di precedenza esatte per ciascuna di queste lingue, senza guardare?

"Dovrei usare le parentesi nelle istruzioni logiche anche dove non è necessario."

Sì, perché due persone li troveranno utili:

• Il prossimo programmatore, che ha conoscenza, competenza o stile può essere diverso

• Il futuro tu che ritorni a questo codice in un secondo momento!

I condizionali complessi sono "algebra booleana", che scrivi in ​​un modo che, beh, lo fa sembrare praticamente esattamente algebra, e useresti sicuramente le parentesi per l' algebra , vero?

Le regole davvero utili sono quelle di negazione:

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

Oppure, in un formato un po 'più chiaro:

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

che è in realtà in modo chiaro solo l'algebra quando scritto come:

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

Ma possiamo anche applicare il pensiero per la semplificazione e l'espansione algebrica:

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

anche se nel codice devi scrivere:

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

o, in un formato un po 'più chiaro:

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

Fondamentalmente, un condizionale è ancora solo un'espressione algebrica e, usando chiaramente la parentesi, è possibile applicare più facilmente le varie regole algebriche che già conosci all'espressione, incluso il vecchio concetto di "semplificare o espandere questa formula".

Userò la parentesi anche se è facoltativa, perché aiuta a capire meglio per tutti, per chi scrive il codice e per chi è pronto a vederlo. Nel tuo caso anche gli operatori booleani hanno la precedenza che all'inizio potrebbe funzionare bene, ma non possiamo dire che ti aiuterà in ogni caso. quindi preferisco utilizzare la parentesi dell'utente in qualsiasi condizione che possa richiederla o facoltativamente.

Sì. Dovresti usare in ogni caso quando ritieni che il tuo codice sarà più chiaro. Ricorda che il tuo codice dovrebbe essere abbastanza chiaro in modo che gli altri possano capire senza leggere i tuoi commenti all'interno del codice. Quindi è una buona pratica usare parentesi e parentesi graffe. Inoltre, tieni presente che potrebbe dipendere dalla particolare pratica della tua azienda / squadra. Mantenere solo un approccio e non mescolare.