Per la maggior parte questa è una preferenza personale, tuttavia ci sono alcune cose da considerare.
Possibili errori
Sebbene si possa sostenere che i bug causati dal dimenticare le parentesi aggiunte sono rari, da quello che ho visto che loro fanno succede occasionalmente (per non dimenticare il famoso IOS goto fail bug). Quindi penso che questo dovrebbe essere un fattore quando si considera lo stile del codice (alcuni strumenti avvertono su fuorviante-indentazione , quindi dipende anche dalla catena di strumenti) .
Codice valido (che legge come potrebbe essere un bug)
Anche supponendo che il tuo progetto non soffra di tali bug, durante la lettura del codice potresti vedere alcuni blocchi di codice che sembrano come potrebbero essere bug - ma non lo sono, prendere parte del tuo mentale cicli.
Iniziamo con:
if (foo)
bar();
Uno sviluppatore aggiunge un commento utile.
if (foo)
// At this point we know foo is valid.
bar();
Più tardi uno sviluppatore si espande su di esso.
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
O aggiunge un blocco nidificato:
if (foo)
while (i--) {
bar(i);
baz(i);
}
O usa una macro:
if (foo)
SOME_MACRO();
"... Poiché le macro possono definire più righe di codice, la macro usa do {...} while (0) per più righe? Dovrebbe perché è nella nostra guida di stile, ma è meglio controllare nel caso in cui!"
Gli esempi sopra sono tutti codici validi, tuttavia più contenuti nel blocco di codice, più devi leggere per assicurarti che non ci siano errori.
Forse il tuo stile di codice definisce che i blocchi multi-linea richiedono una parentesi (non importa cosa, anche se non sono codice) , ma ho visto questo tipo di commenti aggiunti codice di produzione. Quando lo leggi, c'è qualche piccolo dubbio che chiunque abbia modificato quelle righe abbia dimenticato di aggiungere una parentesi graffa, a volte penso che la necessità di ricontrollare funzioni come previsto (specialmente quando si esamina un errore in quest'area del codice ) .
Diff Noise
Un motivo pratico per usare le parentesi per le singole linee è quello di ridurre il rumore diff / .
Cioè, cambiando:
if (foo)
bar();
A:
if (foo) {
bar();
baz();
}
... fa sì che la linea condizionale venga mostrata in un diff come modificato, questo aggiunge un piccolo ma inutile sovraccarico.
- le linee vengono visualizzate come modificate in code-review, se i tuoi strumenti di diffusione sono basati su parole puoi facilmente vedere che solo la parentesi è cambiata, ma ci vuole più tempo per controllare se la linea non è cambiata affatto .
Detto questo, non tutti gli strumenti supportano diff, diff (svn, git, hg ... etc) basati su parole, mostreranno come se l'intera linea fosse cambiata, anche con strumenti fantasiosi, a volte potresti aver bisogno di guardare rapidamente su un semplice diff basato sulla linea per vedere cosa è cambiato.
- strumenti di annotazione (come
git blame ) mostreranno la linea come cambiata, rendendo il tracciamento dell'origine di una linea più passaggio per trovare la modifica reale .
Sono entrambi piccoli e dipendono da quanto tempo trascorri in code-review o track-down che commettono linee di codice modificate.
Un inconveniente più tangibile di avere cambiamenti di linee in più in una diff, il loro potenziale più alto che cambia nel codice causerà conflitti che si uniscono e devono essere risolti manualmente .
C'è un'eccezione a questo, per le basi di codice che hanno { sulla propria linea - non è un problema.
L'argomento diff noise non viene mantenuto se scrivi in questo stile:
if (foo)
{
bar();
baz();
}
Tuttavia questa non è una convenzione così comune, quindi principalmente aggiungendo alla risposta per completezza (non suggerendo che i progetti dovrebbero usare questo stile) .
