Qual è la differenza tra gli stili K & R e One True Brace Style (1TBS)?

La più grande differenza tra K & R e lo stile One True Brace (1TBS) è che nelle istruzioni 1TBS, tutte le if , else , while e for hanno parentesi di apertura e chiusura, anche se non sono necessari Lo scopo è quello di facilitare l'inserimento di nuove affermazioni e sapere esattamente come saranno raggruppate.

Ad esempio:

K & R:

int i;
for (i = 0; i < 10; i++)
  printf("Hi.");

1 cucchiaio:

int i;
for (i = 0; i < 10; i++) {
  printf("Hi");
}

K & R è come questo:

if (x) 
    a();
else {
    b();
    c();
}

Cioè: le parentesi usate solo dove necessario, aprendo il rinforzo sulla stessa riga dell'istruzione di controllo, chiudendo il rinforzo sulla propria linea.

Il "one true brace style" (1TBS o OTBS) trasforma una singola istruzione controllata in un'istruzione composta racchiudendola tra parentesi:

if (x) {
    a();
} else {
    b();
    c();
}

Lo stile Allman va un po 'più in là di 1TBS e impone la spaziatura verticale posizionando il rinforzo di apertura su una linea anche da solo:

if (x) 
{
    a();
}
else 
{
    b();
    c();
}

Modifica:

Sto ancora cercando di capire esattamente come si qualifica come "arrogante" per dire "Dennis Ritchie era un estremamente ragazzo intelligente che non solo ha inventato una buona lingua, ma ha anche inventato un per questo è davvero ottimo. "

Per coloro che insistono sul fatto che sia comunque arrogante, ecco una piccola sfida: vai su Sourceforge, Github (ecc.) e scegli i progetti usando lo stile bretella K & R. Controlla i loro record di bug e commit e prova a trovare un bug singolo causato dallo stile di parentesi che hanno usato.

Se non vuoi fare così tanto lavoro, prova a fare una semplice analisi statistica. Confronta i progetti utilizzando diversi stili di controvento e vedi se puoi mostrare "bimodalità" - una differenza statisticamente significativa nel conteggio degli errori (gravità, ecc.) Correlata con lo stile di rinforzo.

Ho fatto entrambe le cose alcuni anni fa, e non sono riuscito a trovare un singolo bug che potessi attribuire agli stili di rinforzo, né potrei trovare nulla che si avvicini ad una correlazione statisticamente significativa tra i due. In media, quelli che utilizzavano i rinforzi K & R avevano un numero leggermente inferiore di bug, ma la differenza era molto troppo piccola per essere considerata statisticamente significativa.

Da quando è stato attivato, commenterò la situazione con macro multi-statement. Una macro che include più istruzioni ma non le circonda con parentesi, ha un bug. Il mio compito è non scrivere codice che copra quel bug. Al contrario, il mio compito è quello di trovare e sradicare quel bug il più rapidamente possibile.

Scrivere codice nella speranza di nascondere i bug in modo che rimangano non diagnosticati e non fissati sia assolutamente malvagio. Chiamalo arrogante se vuoi, ma non lo vedo nemmeno vicino a negoziabile. I bug dovrebbero essere trovati e riparati, non coperti. Più a lungo esiste, più è probabile che diventeranno molto più difficili e costosi da risolvere.

Il problema, in generale con lo stile di parentesi KR, è nel refactoring del codice. Quando si sposta il codice attorno a esso è facile non notare che non ci sono parentesi attorno a qualcosa, spostarlo in modo errato (o spostare qualcosa sotto di esso pensando che sia condizionato) e poi grattarsi la testa quando qualcosa non funziona più, o essere sfortunato e essere dentro un'area del codice non ben collaudata e il bug passa inosservato fino a quando un cappello nero non trova un modo per sfruttarlo. Un rapido viaggio nel debugger trova facilmente il problema se lo noti, ma se non lo fai ...