Per la maggior parte questa è una preferenza personale, tuttavia ci sono alcune cose da considerare.
Possibili bug
Mentre si può sostenere che i bug causati da dimenticare di parentesi graffe add-in sono rari, da quello che ho visto che essi si verificano di tanto in tanto (per non dimenticare il famoso goto IOS sicuro bug). Quindi penso che questo dovrebbe essere un fattore quando si considera il tuo stile di codice (alcuni strumenti avvertono di indentazione fuorviante , quindi dipende anche dalla tua catena di strumenti) .
Codice valido (che potrebbe sembrare un bug)
Anche supponendo che il progetto non soffre di questi bug, durante la lettura del codice si possono vedere alcuni blocchi di codice che sembrano potrebbero essere bug - ma non sono, prendendo alcuni dei vostri cicli mentali.
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();
Oppure aggiunge un blocco nidificato:
if (foo)
while (i--) {
bar(i);
baz(i);
}
Oppure utilizza una macro:
if (foo)
SOME_MACRO();
"... Dato che le macro possono definire più righe di codice, la macro utilizza do {...} while (0)per più righe? Dovrebbe essere perché è nella nostra guida di stile, ma è meglio controllare per ogni evenienza!"
Gli esempi di cui sopra sono tutti codici validi, tuttavia, più contenuto nel blocco di codice, più è necessario leggere per assicurarsi che non vi siano errori.
Forse il tuo stile di codice definisce che i blocchi multi-linea richiedono un controvento (non importa quale, anche se non sono codice) , ma ho visto questo tipo di commenti aggiunti nel codice di produzione. Quando lo leggi, c'è qualche piccolo dubbio sul fatto che chiunque abbia modificato quelle ultime righe abbia dimenticato di aggiungere una parentesi graffa, a volte sento che la necessità di ricontrollare sta funzionando come previsto (specialmente quando indaga su un bug in questa area del codice) .
Rumore diff
Un motivo pratico per utilizzare le parentesi graffe per le singole linee è ridurre il rumore diff .
Cioè, cambiando:
if (foo)
bar();
Per:
if (foo) {
bar();
baz();
}
... fa apparire la linea condizionale in una diff come modificata, questo aggiunge un piccolo ma inutile sovraccarico.
- le righe vengono visualizzate come modificate nelle revisioni del codice, se i tuoi strumenti di differenziazione sono basati su parole, puoi facilmente vedere che è cambiata solo la parentesi graffa, ma ci vuole più tempo per verificare se la linea non è cambiata affatto.
Detto questo, non tutti gli strumenti supportano il diffing basato su parole, diff (svn, git, hg ... ecc.) Mostrerà come se l'intera linea fosse cambiata, anche con strumenti fantasiosi, a volte potrebbe essere necessario esaminare rapidamente una linea semplice basato su diff per vedere cosa è cambiato.
- gli strumenti di annotazione (come
git blame) mostreranno la linea come modificata, rendendo il tracciamento dell'origine di una linea più un passo per trovare il vero cambiamento.
Questi sono entrambi piccoli e dipendono da quanto tempo dedichi alla revisione del codice o al tracciamento verso il basso che commettono righe di codice modificate.
Un inconveniente più tangibile di avere cambiamenti di linea extra in un diff, la loro maggiore probabilità che cambiamenti nel codice provochino conflitti che si fondono e devono essere risolti manualmente .
C'è un'eccezione a questo, per le basi di codice che hanno {una propria riga: non è un problema.
L' argomento del rumore diff non regge se scrivi in questo stile:
if (foo)
{
bar();
baz();
}
Tuttavia questa non è una convenzione così comune, quindi si aggiunge principalmente alla risposta per completezza (non suggerire che i progetti dovrebbero usare questo stile) .
