¿Cuál es la diferencia entre los estilos K&R y One True Brace Style (1TBS)?

He leído el artículo de Wikipedia sobre los estilos de sangría , pero aún no lo entiendo. ¿Cuál es la diferencia entre K&R y 1TBS?

La mayor diferencia entre K & R y el estilo Brace Verdadero (1TBS) es que en el 1TBS, todos if, else, while, y forlas declaraciones tienen llaves de apertura y cierre, incluso si no son necesarios. El propósito es facilitar la inserción de nuevas declaraciones y saber exactamente cómo se agruparán.

Como ejemplo:

K&R:

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

1TBS:

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

K&R es así:

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

Es decir: las llaves se usan solo donde es necesario, abriendo la llave en la misma línea que la instrucción de control, cerrando la llave en su propia línea.

El "estilo de una llave verdadera" (1TBS u OTBS) convierte una sola declaración controlada en una declaración compuesta encerrándola entre llaves:

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

El estilo Allman va un poco más allá de 1TBS, y fuerza el espaciado vertical al colocar la llave de apertura en una línea también por sí misma:

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

Editar:

Todavía estoy tratando de entender exactamente cómo califica como "arrogante" decir "Dennis Ritchie fue un tipo extremadamente inteligente que no solo inventó un buen lenguaje, sino que también ideó un estilo de corsé realmente bueno para él".

Para aquellos que insisten en que es arrogante de todos modos, aquí hay un pequeño desafío: ve a Sourceforge, Github (etc.) y elige proyectos usando el estilo de llaves K&R. Revise sus registros de errores y confirmaciones, e intente encontrar un solo error causado por el estilo de llave que usaron.

Si no quiere hacer tanto trabajo, intente hacer un análisis estadístico simple. Compare proyectos con diferentes estilos de llaves y vea si puede mostrar "bimodalidad", una diferencia estadísticamente significativa en los recuentos de errores (gravedad, etc.) que se correlaciona con el estilo de arriostramiento.

Hice ambas cosas hace unos años, y no pude encontrar un solo error que pudiera atribuir a los estilos de refuerzo, ni pude encontrar nada que se acercara a una correlación estadísticamente significativa entre los dos. En promedio, los que utilizan K & R arriostramiento tenían ligeramente menos errores, pero la diferencia era mucho demasiado pequeña para calificar como estadísticamente significativo.

Desde que se mencionó, comentaré la situación con macros de múltiples declaraciones. Una macro que incluye varias declaraciones pero no las rodea con llaves, tiene un error. Mi trabajo no es escribir código que cubra ese error. Por el contrario, mi trabajo es encontrar y erradicar ese error lo más rápido posible.

Escribir código con la esperanza de que cubra los errores para que permanezcan sin diagnosticar y sin reparar es francamente malo. Llame a eso arrogante si lo desea, pero no lo veo ni siquiera como negociable. Los errores deben ser encontrados y reparados, no cubiertos. Cuanto más tiempo exista, más probable es que se vuelvan mucho más difíciles y costosos de arreglar.

El problema, en general con el estilo de llaves KR está en la refactorización de código. Al mover el código, es fácil pasar por alto que no hay llaves alrededor de algo, moverlo incorrectamente (o mover algo debajo de él pensando que se ejecuta condicionalmente) y luego rascarse la cabeza cuando algo ya no funciona, o ser desafortunado y estar en un área de código no está bien probada y el error pasa desapercibido hasta que un sombrero negro encuentra la manera de explotarlo. Un viaje rápido al depurador encuentra fácilmente el problema si lo nota, pero si no lo hace ...