Quelle est la différence entre les styles K & R et One True Brace Style (1TBS)?

J'ai lu l'article de Wikipedia sur les styles d'indentation , mais je ne comprends toujours pas. Quelle est la différence entre K & R et 1TBS?

La plus grande différence entre K & R et un vrai style Brace (1TBS) est que dans le 1TBS, tous if, else, whileet fordéclarations ont accolades ouverture et de clôture, même si elles ne sont pas nécessaires. Le but est de faciliter l’insertion de nouvelles instructions et de savoir exactement comment elles seront regroupées.

Par exemple:

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 est comme ça:

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

C'est-à-dire: les accolades utilisées uniquement si nécessaire, l'ouverture de l'accolade sur la même ligne que l'instruction de contrôle, la fermeture de l'accolade sur sa propre ligne.

Le "style à une accolade vraie" (1TBS ou OTBS) transforme une seule instruction contrôlée en une instruction composée en la mettant entre accolades:

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

Le style Allman va un peu plus loin que 1TBS et impose un espacement vertical en plaçant l'accolade d'ouverture sur une ligne également:

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

Modifier:

J'essaie toujours de comprendre exactement comment il est qualifié d '"arrogant": "Dennis Ritchie était un type extrêmement intelligent qui a non seulement inventé un bon langage, mais également un style de doublure vraiment bon."

Pour ceux qui insistent pour que ce soit arrogant de toute façon, voici un petit défi: allez à Sourceforge, Github (etc.) et choisissez des projets utilisant le style K & R brace. Parcourez leurs enregistrements de bugs et de commits et essayez de trouver un seul bogue causé par le style d'accolade utilisé.

Si vous ne voulez pas faire autant de travail, essayez de faire une simple analyse statistique. Comparez les projets en utilisant différents styles d'accolade et voyez si vous pouvez afficher la "bimodalité" - une différence statistiquement significative dans le nombre de bogues (gravité, etc.) en corrélation avec le style de contreventement.

Il ya quelques années, j’ai fait les deux, et je n’ai trouvé aucun bug que je pourrais attribuer aux styles de contreventement, et je n’ai rien trouvé qui soit proche d’une corrélation statistiquement significative entre les deux. En moyenne, ceux qui utilisaient des attelles K & R avaient légèrement moins de bogues, mais la différence était beaucoup trop petite pour être considérée comme statistiquement significative.

Puisqu'il a été soulevé, je commenterai la situation avec les macros à plusieurs instructions. Une macro qui inclut plusieurs instructions, mais ne les entoure pas d'accolades, a un bogue. Mon travail n’est pas d’écrire du code qui cache ce bogue. Bien au contraire, mon travail consiste à rechercher et à éliminer ce bogue le plus rapidement possible.

Écrire du code dans l’espoir qu’il recouvre des bugs afin qu’ils ne soient ni diagnostiqués ni corrigés est tout simplement diabolique. Appelez cela arrogant si vous voulez, mais je ne vois pas cela aussi proche de négociable. Les bugs doivent être trouvés et corrigés, pas dissimulés. Plus le système existe longtemps, plus il est probable qu’il deviendra beaucoup plus difficile et coûteux à réparer.

Le problème, en général avec le style d'accolade KR, est le refactoring de code. Lorsque vous déplacez du code, il est facile de rater le fait qu'il n'y a pas d'accolade autour de quelque chose, déplacez-le incorrectement (ou déplacez-le dessous en pensant qu'il est exécuté sous condition), puis grattez votre tête lorsque quelque chose ne fonctionne plus, ou soyez malheureux et soyez dans une zone de code mal testée et le bogue passe inaperçu jusqu’à ce qu’un chapeau noir trouve le moyen de l’exploiter. Un petit tour dans le débogueur trouve facilement le problème si vous le remarquez, mais si vous ne le faites pas ...