Si dovrebbe conoscere a fondo la precedenza dell'operatore?

StackOverflow https://stackoverflow.com/questions/465706

Domanda

Il programmatore dovrebbe conoscere a fondo la precedenza dell'operatore? Usare le parentesi graffe per raggruppare le espressioni dovrebbe andare bene, no? Uso sempre le parentesi graffe per essere più sicuro. E quando mi viene posta una domanda sulla precedenza, non posso rispondere prontamente.

È stato utile?

Soluzione

Per operatori molto comuni: sì, vale la pena conoscerlo. Se metti le parentesi attorno a tutto che altrimenti farebbero affidamento sulla precedenza dell'operatore, il tuo codice sarebbe illeggibile (o facilmente confuso con Lisp).

Per operatori più oscuri, ho esplicitamente evitato di impararli. Se comincio a dare troppe cose per scontate che non posso ragionevolmente aspettarmi che altri sviluppatori sappiano, inizierò a scrivere codice che posso leggere facilmente, ma nessun altro può farlo. Il miglior esempio sono gli operatori a turni. Non so nemmeno (di sicuro - ho una vaga idea) di quali di questi sarebbero trattati allo stesso modo senza le parentesi, ma sono assolutamente sicuro che sia più chiaro: 

int x = (y << shift) + offset;

o 

int x = y << (shift + offset);

Altri suggerimenti

Sì, è importante comprendere la precedenza dell'operatore. Tuttavia, penso che valga la pena usare le parentesi per chiarire perfettamente le tue intenzioni. Aiuterà la leggibilità e la manutenibilità.

Anni fa ho visto questa tabella di precedenza per C:

  • La moltiplicazione e la divisione avvengono prima dell'aggiunta e della sottrazione.
  • Usa le parentesi.

È leggermente semplificato, ma ha l'idea giusta.

Uso un cheat sheet per tutti tranne gli operatori aritmetici più comuni. Se qualcosa è meno complicato, uso parentesi esplicite per chiarire le mie intenzioni.

Il motivo per cui mi piace usare una guida scritta piuttosto che memorizzare la precedenza è che lavoro spesso in più lingue con regole leggermente diverse. Memorizzare qualsiasi cosa oltre gli operatori più comuni può portare a errori quando inizio a fare troppo affidamento sulla mia memoria.

Dovresti capirlo, ma non dovresti presumere che lo faranno gli altri. Uso sempre la parentesi per rendere esplicita la precedenza.

Conosco le basi (ad es. divisione e moltiplicazione superiori all'addizione e alla sottrazione), ma dovrei cercare qualcosa di più esoterico.

Di solito uso le parentesi per chiarire la mia intenzione. Penso che legga meglio ed eviti errori dovuti a ipotesi errate.

Certamente non può far male, e può aiutarti a leggere il codice con sottigliezze di precendenza scritte da altri.

In pratica, tuttavia, è probabilmente meglio non supporre che coloro che gestiscono il tuo codice abbiano la stessa competenza, quindi mentre dovresti essere in grado di leggere questo codice potresti non voler scrivere codice che sfrutti troppo le interazioni. Meglio usare costrutti inconfondibili, anche se questo significa alcune parentesi extra qua e là.

Sono con te su questo; usare le parentesi graffe per rendere esplicita la precedenza è sempre una buona idea. Semplifica la lettura del codice e le tue intenzioni sono esplicite.

Detto questo, dovresti sapere dove cercare le informazioni sulla precedenza dell'operatore, nel caso in cui stai mantenendo il codice altrui.

Praticamente: non proprio. Se è così complicato che devi conoscere la precedenza dell'operatore, probabilmente dovresti comunque suddividere l'espressione in blocchi. Inoltre, la parentesi ti salverà!

Professionalmente: non ci vuole molto per imparare l'ordine per la tua lingua preferita e può tornare utile quando leggi il codice di altre persone. Se non altro, tienilo su un foglietto sul muro del cubo.

Dovresti capirlo per poter leggere il codice scritto da qualcuno che non ha usato le parentesi ovunque.

Non credo " sempre-parentesi graffe " è una buona regola empirica. Il codice che contiene troppi genitori diventa più difficile da leggere del necessario. Come: 

(a * b) + c

è semplicemente stupido. C'è un equilibrio da qualche parte e la sfida è trovarlo. Come tante altre cose si tratta di applicare il buon senso.

Rapido, che ha una precedenza maggiore in T-SQL: AND rispetto a OR. 

SELECT c.Name
FROM [Customer] c LEFT JOIN [Order] o
  ON c.CustomerKey = o.CustomerId
WHERE c.Name like 'B%'
  OR c.Name like 'Z%'
  AND o.CustomerId is NULL

Dopo aver appreso la precedenza di questi operatori al punto in cui fai affidamento su tale precedenza , sei condannato a:

  • Usali nel modo sbagliato.
  • Subisci gli errori degli altri, che non impareranno questi operatori e non potranno leggere il tuo codice.

Penso che sia importante capire le regole di base della predidenza. Trovo che conoscere i dettagli nitidi e grintosi non valga la pena. Principalmente perché qualsiasi caso in cui la predecenza è ambigua può essere risolto con un semplice set di parentesi. In secondo luogo perché non tutti li conoscono ed è meglio rendere il codice leggibile dagli utenti del tuo gruppo.

Una volta al college, conoscevo a memoria tutte le regole della predenza. Una volta entrato nel mondo reale ho scoperto che molte persone non le conoscevano a memoria. Se avessi controllato un codice valido che dipendeva da alcune regole di predecence ottenevo costantemente lo stesso feedback & Quot; aggiungi parentesi per rendere ovvio & Quot ;.

C'è una terza opzione. Invece di memorizzare tutte quelle regole, o usando le parentesi per assicurarsi di tutto ...

Se la tua espressione è così lunga che non è chiaro cosa accada per primo, suddividila in più righe, usando variabili temporanee per risultati intermedi. Quindi stai introducendo la chiarezza senza il disordine delle parentesi e puoi usare nomi descrittivi per le variabili temporanee per rendere le cose ancora più chiare.

No!

Se non si è sicuri della precedenza, è probabile che chiunque legga il codice possa interpretarlo in modo errato.

Se non sei sicuro solo 

 ( .. )
i bit di codice rilevanti, allora non c'è ambiguità per te o per chiunque altro.

Non ho mai un controllo del 100% sulle regole di precedenza perché lavoro in diverse lingue (C, C ++, perl, bash e una volta ogni tanto un trattino di TCL / TK.). In varie occasioni nel corso degli anni ho lavorato con diversi linguaggi di assemblaggio e un compilatore non conforme o due.

NON POSSO mantenere le regole di precedenza completamente dettagliate nella mia testa - devo passare da un set di regole troppo spesso.

Sì per:

  • * / + -
  • amp &; & Amp; || E oppure

No / Forse:

  • lt &; Lt &; gt &; gt &; & Amp; | ^

È molto facile ingannarsi quando si scrive a == a & some_flag.

Anche se suggerirei non di imparare le regole di precedenza, usando le parentesi e i provvisori per chiarezza (ricorda: il codice deve essere letto da esseri umani ), a volte un operatore la tabella di precedenza è utile.

Supponendo che tu conosca il concetto di precedenza dell'operatore (che presumo facciano tutti, dalle lezioni di matematica), preferirei non assumere alcuna conoscenza da parte del lettore ...

... eccetto per il buon senso: come è stato sottolineato, espressioni come a * b + c possono essere comprese usando la conoscenza delle lezioni di matematica. Espressioni booleane come a < 4 && a > 0 possono essere comprese perché è più logico avere confronti più stretti di &&.

D'altra parte, non esiste un senso comune per mescolare operatori bit per bit con l'aritmetica normale, quindi usare meglio le parentesi lì. Inoltre, non esiste alcun senso comune per la precedenza di || rispetto a <=> (o è stato il contrario?), Quindi utilizzare anche le parentesi lì.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top