Les accolades doivent-elles apparaître sur leur propre ligne? [fermé]


273

Les accolades doivent-elles être alignées ou non? Qu'est-ce que tu en penses?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

ou devrait-il être

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

ou même

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

S'il vous plaît soyez constructif! Expliquez pourquoi, partagez vos expériences, sauvegardez-le avec des faits et des références.


105
Je trouve le "== vrai" plus distrayant que le choix du placement de l’attelle.
Dan Dyer

11
@Dan: Je pense qu'expliquer toujours l'expression conditionnelle aide beaucoup à la clarté.
Wizard79

4
Cela serait uniquement dû au fait que votre IDE / éditeur ne prend pas en charge la reconnaissance correspondante entre accolades.
leeand00

4
@ leeand00: certains d'entre nous impriment encore du code complexe / inconnu pour l'étudier / l'annoter. Une bonne jolie imprimante atténue cependant la plupart des problèmes.
Shog9

2
triste la question est fermée. Après un certain temps d'utilisation de la syntaxe basée sur l'indent, je suis passé (peut-être bizarre) à une autre structure d'accolades. Comme votre premier mais ferme accolade dans la dernière ligne du bloc. (après la ligne de code)
Cnd

Réponses:


88

Quand j'étais étudiant, j'avais l'habitude de placer des accolades sur la même ligne, de sorte qu'il y ait moins de lignes et que le code soit imprimé sur moins de pages. Regarder un caractère entre crochets imprimé comme la seule chose dans une ligne est ennuyeux. (environnement, gaspillage de papier)

Toutefois, lors du codage d'applications volumineuses, l'utilisation de lignes comportant uniquement des accolades est abordable, compte tenu de la sensation de "regroupement" qu'elle procure.

Quel que soit le style que vous choisissez, soyez cohérent, afin que votre cerveau ne traite pas de frais généraux pour traiter plusieurs styles dans des morceaux de code associés . Dans différents scénarios (comme ci-dessus), je dirais qu'il est correct d'utiliser différents styles, il est plus facile de "changer de contexte" à un niveau élevé.


6
Par contre, l’attelle de la nouvelle ligne est une norme ANSI, pas K & R. Mais la beauté des normes réside dans le fait qu’il existe une multitude de normes différentes (voir aussi uncyclopedia.wikia.com/wiki/AAAAAAAAA ! Sur la Uncyclopedia).
Quandary

"il y a moins de lignes" J'ai des téraoctets d'espace et beaucoup de pixels. Pourquoi devrais-je me préoccuper d'utiliser plus de lignes?
12431234123412341234123

1
@ 12431234123412341234123: Je pense qu'il veut dire parce que certaines personnes impriment le code pour révision. Et chaque nouvelle ligne non indispensable est gaspillée en papier, ou un km² de forêt perdue à grande échelle. Cependant, si vous ne l'imprimez pas (certainement pas), ANSI est bien meilleur que K & R. De plus, toute personne souhaitant imprimer devrait probablement utiliser un formateur de code automatisé - il devrait donc s'agir d'une question d'outillage et non de style de code.
Quandary

247

Vous ne devriez jamais faire la 3ème méthode.

Le fait de lésiner sur des accolades pourrait vous épargner quelques frappes au clavier la première fois, mais le prochain codeur ajoute quelque chose à votre clause else sans s'apercevoir que le blocage manque; les accolades vont faire beaucoup souffrir.

Ecrivez votre code pour d'autres personnes.


113
J'aimerais savoir d'où vient ce petit bout de sagesse. Parce qu'écrire votre code pour des gens qui ne se donneront pas la peine de le lire est à peu près aussi inutile que possible ...
Shog9

69
Le deuxième programmeur peut ajouter ses propres accolades lorsqu'il ajoute quelque chose. Il n'est pas stupide, et dans une convention de codage qui encourage l'omission d'accolades pour des choses simples comme celle-ci, il saura regarder.
Ken Bloom

25
Les accolades facultatives ne sont pas facultatives. Il y a peu de décisions de conception pires qui ont été prises en C et reportées à ses descendants. Qu'il se perpétue dans un langage aussi récent que C # me fait rage.
Adam Crossland

28
Peu importe votre niveau d'intelligence ou l'enracinement de la norme de codage des curlies omises sur une seule ligne: si vous cherchez à résoudre un problème ou un bogue, vous aurez probablement tendance à oublier que les curlies ont été omises. Et pour un total de 2 secondes de travail, est-ce vraiment si grave d'être explicite?
Jordanie

11
Il y a un avantage au style n ° 3 qui vous manque tous: vous obtenez plus de code sur votre écran à la fois.
Loren Pechtel le

203

Pendant longtemps , je l' ai soutenu qu'ils étaient de valeur égale, ou si très proche de l' égalité que le gain possible en faisant bien, le bon choix était loin, au- dessous du coût de discuter à ce sujet.

Être cohérent est important , cependant. Alors j'ai dit, jetons une pièce et commençons à écrire du code.

J'ai déjà vu des programmeurs résister à un tel changement. Passer à autre chose! J'ai changé plusieurs fois dans ma carrière. J'utilise même des styles différents dans mon C # que dans mon PowerShell.

Il y a quelques années, je travaillais au sein d'une équipe (environ 20 développeurs) qui a décidé de demander son apport, puis de prendre une décision, puis de l'appliquer à l'ensemble de la base de code. Nous aurions une semaine pour décider.

Beaucoup de gémissements et à couper le souffle. Beaucoup de "J'aime mon chemin, parce que c'est mieux" mais pas de substance.

Alors que nous étions en train d’étudier les points les plus fins de la question, quelqu'un a demandé comment traiter cette question dans l’ordre habituel:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Notez que l'emplacement de la liste de paramètres et le début du corps ne sont pas immédiatement évidents. Comparer aux:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Nous avons lu quelques explications sur la façon dont les gens du monde entier ont traité ce problème et nous avons trouvé le schéma consistant à ajouter une ligne vierge après l'accolade ouverte:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

Si vous voulez faire une pause visuelle, vous pouvez également le faire avec une attelle. Ensuite, vos ruptures visuelles deviennent également cohérentes.

Edit : Deux alternatives à la solution 'extra blank line' lorsque K & R est utilisé:

1 / Indenter les arguments de la fonction différemment du corps de la fonction

2 / Placez le premier argument sur la même ligne que le nom de la fonction et alignez les arguments supplémentaires sur les nouvelles lignes avec ce premier argument

Exemples:

1/

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/Modifier

Je persiste à dire que la cohérence est plus importante que d’autres considérations, mais si nous n’avons pas de précédent établi , nous devons nous attendre le lendemain.


33
Pour votre information, je peux sembler être une personne raisonnable, mais je suis en fait un fou. Pour les blocs simples à une seule ligne, je n’utiliserai ni accolade ni nouvelle ligne, ce qui signifie que «if (foo) bar ()» ne contient qu’une seule ligne. Je m'efforce de rendre mon code assez simple pour que ce ne soit pas un problème.
Jay Bazuzi

38
Je suis venu ici pour poster exactement cela. Des tonnes de personnes qui gardent l'accolade ouvrante sur la même ligne la suivent avec une ligne vierge (en particulier au début des classes et des méthodes) car sinon, il est difficile de séparer l'en-tête classe / méthode du corps. De toute façon, si vous souhaitez utiliser une ligne supplémentaire de toute façon, vous pouvez également y placer le corset et profiter du bénéfice supplémentaire de l'indentation, qui est plus facile à voir.
Yevgeniy Brikman

27
Je n'ai pas vu la ligne blanche - je suis plus familier avec le double retrait des paramètres de MyFunction () lorsqu'ils s'égarent sur une autre ligne.
Armand

34
Découper les paramètres sur plusieurs lignes comme cela est exaspérant.
Fosco

10
L'argument "paramètre de fonction" est un fil rouge. De toute évidence, les arguments devraient être à double intention. Pas de problème pour le distinguer du code suivant.
David Ongaro

99

Les règles cardinales sont les suivantes:

  1. Suivez les normes de codage existantes du projet.
  2. S'il n'y a pas de norme de codage et que vous modifiez une base de code existante appartenant à quelqu'un d'autre - soyez cohérent avec le style du code existant, peu importe à quel point vous l'aimez.
  3. Si vous travaillez sur un projet écologique - discutez avec d'autres membres de l'équipe et obtenez un consensus sur une norme de codage formelle ou informelle.
  4. Si vous travaillez sur un projet novateur en tant que développeur unique, faites-vous votre propre idée, puis soyez impitoyablement cohérent.

Même si vous n'avez aucune contrainte externe, il est préférable (IMO) de rechercher une norme de codage existante (largement utilisée) ou une directive de style, et d'essayer de la suivre. Si vous adoptez votre propre style, vous risquez de le regretter dans quelques années.

Enfin, un style implémenté / implémentable à l'aide de vérificateurs de style et de formateurs de code existants est préférable à un style qui doit être "appliqué" manuellement.


10
Cette réponse mérite plus de votes.
AShelly

1
la cohérence est la clé
MediaVince

70

L'avantage de la première méthode est qu'elle est plus compacte verticalement. Vous pouvez ainsi insérer plus de code sur votre écran. C'est pourquoi je la préfère. Le seul argument que j'ai entendu en faveur de la deuxième méthode est qu'il est plus facile d'associer des crochets d'ouverture et de fermeture, mais la plupart des IDE ont un raccourci clavier pour cela, et c'est en fait une fausse déclaration, au lieu d'associer un crochet d'ouverture à une fermeture. crochet, vous pouvez associer un crochet de fermeture à l’expression "début de bloc" (si, sinon, pour, tout) sur le même niveau d’indentation, il est donc tout aussi facile de déterminer où se trouve le début du bloc.

Je ne vois aucune raison de gaspiller une ligne entière juste pour un crochet lorsque la construction précédente pour / while / if indique déjà visuellement le début d'un bloc.

Cela dit, j'estime que le crochet de fermeture devrait être dans sa propre ligne car nous avons besoin de quelque chose pour indiquer la fin d'un bloc et sa structure d'indentation de manière visible.


12
Non ... Je dis pourquoi pourquoi réduire la quantité de code qui peut tenir sur votre écran en faisant quelque chose qui n'ajoute pas à la clarté du code?
EpsilonVector le

6
Quand j'ai commencé à coder, j'aimais chaque attelle sur sa propre ligne. Maintenant, je préfère la première méthode
NimChimpsky, le

57
Il existe de nombreuses recherches qui remontent au début de l'âge de vapeur (Weinberg, "Psychology of Computer Programming"), qui montrent que la compréhension du programmeur diminue de façon spectaculaire lorsque la quantité de code à afficher est supérieure à ce que l'on peut être vu en même temps (un écran, une page d’imprimante). Ce phénomène milite pour que l’espace vertical soit considéré comme une ressource précieuse à ne pas gaspiller gratuitement. La première méthode est donc préférable.
John R. Strohm

10
LOL @ "gaspiller une ligne ENTIER". OMG! Pas ça!! = P
Nick Spreitzer

6
@ Julio Au collège, je privilégiais fortement la méthode 1 et ne pouvais supporter de lire la méthode 2. Après avoir travaillé pour une entreprise utilisant C #, où la méthode standard est la méthode 2, j'ai tout aussi bien apprécié cette méthode. Je peux maintenant lire ou utiliser soit; ni l'un ni l'autre ne me dérange. Les personnes qui ont une réaction fortement opposée à l’un ou à l’autre réagissent généralement de manière excessive à quelque chose qu’elles ne connaissent pas bien.
KChaloux

46

je préfère

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

plus de

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

parce que la ligne you.postAnswer();est beaucoup plus facile à lire et à trouver à première vue. Dans un deuxième temps, il se fond avec la ligne au-dessus de lui ( you.hasAnswer()), ce qui oblige mes yeux à se concentrer davantage pour le lire.


7
Cela est vrai jusqu'à ce que votre programme dépasse la hauteur de votre écran. ;)
weberc2

13
@ weberc2 Je pense que lorsque votre programme dépasse la hauteur de l'écran, deux lignes de moins ne changeront pas beaucoup.
Mageek

13
Il y a 10 ans, j'aurais été d'accord sur l'espace à l'écran. Aujourd'hui, j'utilise un écran 1920 * 1200. Cela correspond à BEAUCOUP de code, plus que mon cerveau ne peut traiter à la fois. La première méthode me permet de revenir en arrière et de voir les différentes portées s'ouvrir / se fermer sans avoir à le lire.
LightStriker

3
Je ne pourrais jamais comprendre pourquoi j'ai préféré cette méthode, mais c'est exactement pour cela.
Declan McKenna

2
@Mageek C'est tardif, mais ce n'est pas 2 lignes, c'est 2 lignes pour chaque scope. C'est O (N), pas O (1). Je ne ressens pas vraiment ce point; il est plus important que vous choisissiez un style permettant de lire de longues listes de paramètres.
Weberc2

38

Je préfère la première méthode. Les bretelles ne valent absolument pas la ligne séparée.

La chose est que les accolades ne sont pas importants. Ce ne sont que des corbeilles syntaxiques , ce qui est absolument inutile pour comprendre à quoi sert le code, son objectif et la façon dont il est implémenté. Ils ne sont qu’un hommage à l’ancien langage de type C où le regroupement visuel des opérateurs était impossible en raison du faible espace disponible sur l’écran.

Il existe des langages (Python, Haskell, Ruby) qui conviennent sans accolades. Cela ne fait que confirmer que les accolades sont des ordures et ne devraient pas mériter une ligne pour eux chaque fois que possible:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}

7
Je ne connais pas Haskell ni Ruby, mais Python est sensible aux espaces, raison pour laquelle il n'est pas nécessaire d'avoir d'accolades ou d'autres délimiteurs pour désigner les blocs. Les accolades ne sont pas simplement du bruit syntaxique; ils servent un but réel.
Robert Harvey

14
@ Robert, En C, vous devez faire les deux espaces et accolades. En Python, vous ne devriez faire que des espaces. Ce qui est mieux?
P Shved

5
@Pavel, en C ', vous n'avez pas besoin de blanc.
Ken Bloom

7
Les programmes @KenBloom C sans espace sont impossibles à lire. Donc, vous devez les faire quand même.
P expédié

6
Que les accolades soient une bonne idée ou non, la simple existence de langages qui ne les utilisent pas ne semble pas être un argument pour ou contre. Cela suggère simplement qu’il est possible d’avoir une langue sans eux, et non qu’il s’agit d’une conception de langue bonne ou mauvaise.
Jason

37

Utilisez Python et évitez complètement l’argument.


17
+1SyntaxError: not a chance
Seth

6
Ce n'est tout simplement pas une option pour la très grande majorité des projets. De plus, l'indentation pour le groupement a sa part de problèmes.
Bryan Oakley

@ Bryan, je réalise que ce n'est pas très pratique. Je pensais juste que c’était un point de vue qui devait être diffusé, plus fort qu’un simple commentaire. Et je n'ai jamais rencontré les problèmes causés par l'indentation que vous suggérez, probablement parce que je ne mélange pas les onglets et les espaces.
Mark Ransom

Utilisez Go pour éviter complètement l'argument (plus la saisie statique, la vitesse et un compilateur!) :)
weberc2

4
Appuyez ensuite trop souvent sur la barre d'espace et regardez le compilateur / interprète se moquer de vous. Cela n'arrivera pas dans la plupart des langues préparées
Pharap

28

La position des accolades devrait être

métadonnées

configurable dans l'IDE par le programmeur. De cette façon, ces accolades dans tout le code, quel que soit leur auteur, se ressemblent.


7
Entièrement d'accord. C'est une présentation et non des données.
Petruza

Le problème est que, si vous laissez chacun définir ses propres règles, les choses se gâtent très rapidement à mesure que les validations sont effectuées.
Andy

1
@Andy: C'est exactement le but, l'EDI va changer son apparence, mais seulement dans l'EDI! La source réelle ne sera pas touchée. Pour le contrôle de version, vous pouvez ajouter des crochets qui traduisent le réglage des accolades en une situation courante, de sorte que tout le monde extrait le code de la même manière.
klaar

@klaar Chaque IDE moderne que j'ai utilisé changera les tabulations en espaces et déplacera les accolades sur leur propre ligne ou à la fin de la ligne "d'ouverture"; Je ne suis pas sûr de savoir pourquoi vous pensez que la source n'est pas touchée dans ces cas, et c'est la raison de mon commentaire. Il est généralement modifié par les IDE en fonction des paramètres des développeurs, ce qui signifie qu'au cours d'une validation, je verrai de nombreuses modifications qui ne sont que du bruit, car les accolades ont été déplacées vers leur propre ligne, masquant ainsi le changement ACTUEL que quelqu'un a fait.
Andy

@Andy: N'y a-t-il pas la possibilité d'utiliser des crochets qui convertissent ces divergences concernant les espaces et les accolades en un commit standard standard uniforme, afin de contourner le problème de bruit que vous avez décrit? Dans les deux cas, un système de gestion de versions approprié devrait transcender les petites choses comme les espaces blancs ou autres choses absurdes.
Klaar

19

Ça dépend.

Si je code en Javascript ou jQuery, j'utilise le premier formulaire:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Mais si je code en C #, j'utilise le second formulaire, car c'est la façon canonique de le faire en C #.

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Notez que votre exemple peut être écrit

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

en C #.


1
Il peut être écrit dans beaucoup de langages comme celui-ci, car une instruction de bloc est une instruction. Ajouter! :-)
Tamara Wijsman le

2
Selon les "Directives pour la conception du cadre", la "manière canonique" consiste à placer l'accolade ouvrante sur la même ligne (c'est-à-dire la première forme). Juste dire ...
Uwe Honekamp

3
@Uwe: Peut-être. Mais Microsoft a adopté l'approche "alignement d'accolades" pour tous ses exemples MSDN C #, et elle est intégrée à Visual Studio, donc ...
Robert Harvey

@Uwe: C'est le livre de Cwalina et il est terriblement nommé car c'est beaucoup plus que cela. Le FDG sur MSDN n’a rien à dire à ce sujet. Aussi je me demande, pourquoi le cadre de conception lignes directrices rien dire sur C # codage pratique?
R. Martinho Fernandes

3
En fait, vous devriez mettre des accolades sur la même ligne en Javascript. Vous pouvez provoquer des erreurs si les accolades sont sur leur propre ligne. Par exemple, voir encosia.com/…
Joseph Hansen,

18

Je préfère le premier car il m'est plus difficile de voir l'erreur dans cet exemple.

if (value > maximum);
{
    dosomething();
}

que dans cet exemple

if (value > maximum); {
    dosomething();
}

Le ; {tout me semble plus faux qu'une ligne se terminant par ;donc je suis plus susceptible de le remarquer.


11
Vous faites valoir un bon argument, mais personnellement, cela ne m'est jamais arrivé qu'une fois au cours de mes cinq années de programmation. Je n'arrivais pas à comprendre pourquoi cela n'exécutait pas, l'ai posté sur SO et quelqu'un m'a rapidement fait remarquer le point-virgule. Cependant, chaque fois qu'il est condensé pour utiliser cette ligne de moins, je le lis plus difficilement.
JD Isaacks

6
Le "; {" ressemble à une sorte de visage grincheux clignotant ou peut-être à une personne avec une moustache.
Glenatron

+1 Excellent exemple de réponse: erreur très subtile, facilement oubliée. Pensée provoquant aussi sur la mise en page montrant cela.
therobyouknow

10
Bien sûr, tout IDE décent signalera l’instruction de contrôle vide et tout compilateur décent émettra un avertissement.
Dunk

@Dunk Le seul défaut de votre argument (avec lequel je suis tout à fait d'accord) est que tant de personnes utilisent actuellement des langages interprétés (JavaScript, PHP, etc.) qu'un nombre élevé de "programmeurs" ne connaitraient pas un compilateur à partir d'un double latté.
Craig

15

Je préfère une légère variante de 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Pourquoi?

  • Je pense que toujours mettre des accolades sur leur propre ligne diminue la lisibilité. Je ne peux insérer qu'une certaine quantité de code source sur mon écran. Le style de support 2) crée des algorithmes de soulèvement comportant de nombreuses boucles imbriquées et conditionnelles extrêmement longues.

  • Cependant, je veux elsecommencer sur une nouvelle ligne car ifet elseappartiennent ensemble, visuellement. S'il y a un support devant le else, il est beaucoup plus difficile de repérer ce qui appartient à quoi.

  • 3) se disqualifie. Nous savons tous ce qui peut arriver de mal si vous omettez les parenthèses et si vous les oubliez.


1
J'ai vu celui-ci autour de mon travail. C'est intéressant.
Almo

1
J'aime aussi mieux ce style, car cela me permet de mettre un commentaire au-dessus de la elseligne si nécessaire et / ou de mettre une ligne vierge entre le bloc if et le bloc else pour que les choses soient moins encombrées. Le style de support n ° 2 ne fait rien d’autre que distancer les actions des conditions. Cela dit, mon préféré est sans aucun doute le style sans support de python :)
sayap

4
S'il est important de maximiser le nombre de lignes de code à l'écran, supprimez simplement les nouvelles lignes. Vous pourrez obtenir beaucoup de lignes sur un seul écran. Je préfère ne rien avoir qui me fasse faire une pause et réfléchir en lisant, c.-à-d. ma définition de plus lisible. Avec les accolades, mon esprit les ignore. Sans les accolades, mon esprit doit faire une pause et aligner les blocs de contrôle. Pas une longue pause, mais une pause quand même.
Dunk

1
Oui, si et vont ensemble ensemble, MAIS de même {et} et comme} est sur une ligne séparée, {devrait également être sur une ligne séparée. "Je ne peux insérer qu'une certaine quantité de code source sur mon écran" Et c'est exactement pourquoi dire 3: ce serait "se disqualifier" n'est pas une option du tout. Après une décennie de travail avec 3) je n’ai jamais oublié d’ajouter des crochets lors de l’ajout d’une nouvelle ligne de code, et je ne connais personne qui en ait jamais eu. Si je dois adapter le code aux personnes qui ne peuvent pas lire correctement, où finit-il? Cesser d'utiliser certaines fonctionnalités du langage, car certains lecteurs de codes risquent de ne pas les comprendre?
Kaiserludi

10

J'ai lu quelque part que les auteurs de certains livres voulaient que leur code soit formaté comme ceci:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Mais les contraintes d'espace de la part de leur éditeur impliquaient qu'ils devaient utiliser ceci:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Maintenant, je ne sais pas si c'est vrai (car je ne le trouve plus), mais ce dernier style est très répandu dans les livres.

Sur le plan personnel, je préfère les crochets sur une ligne séparée, comme suit:

a) ils indiquent une nouvelle portée
b) il est plus facile de repérer quand vous avez une incompatibilité (bien que ce soit moins un problème dans un IDE qui met en évidence les erreurs pour vous).


... La deuxième option facilite également vos deux points (avec l'indentation seule servant l'objectif du combo accolade / indentation). :)
weberc2

10

Ah, le seul vrai style de bretelle .

Tout y est pour un chemin sacré - même un prophète (Richard "mon chemin ou l'autoroute" Stallman).

Le gars avait tellement tort à propos de tant de choses, mais GNU est au top en matière de croisillons.


[Mise à jour] J'ai vu la lumière et adore maintenant Allman


9
Je ne vois pas l'intérêt du style GNU, si ce n'est qu'il modélise le code lisp. On dirait que beaucoup de travail pour peu d'avantages.
Robert Harvey

Je ne connais personne qui utilise le style GNU. 1TBS tout le chemin.
Jé Queue

Vous ne pouvez pas faire pire que deux niveaux d'indentation par bloc, sauf pour le style lisp, bien sûr, cela va sans dire.
ergosys

4
+1 pour le lien sur les styles d'accolade. Cela montre que quel que soit votre style, beaucoup de gens formidables ne sont pas d’accord avec vous.
Florian F

@ RobertHarvey Il n'y a pas de travail supplémentaire, si c'est le cas, vous n'utilisez pas le bon outil pour écrire du code ou ne le configurez pas correctement. L'avantage est un code beaucoup plus lisible, vous voyez très rapidement toutes les erreurs dans le support et vous pouvez facilement lire uniquement le code tout en ignorant les sous-blocs.
12431234123412341234123

9

Deuxième exemple, je suis très fort en lisibilité. Je ne peux pas supporter de regarder si les blocs d'une autre manière = (


1
La recherche indique qu'il est plus facile de lire un code compact une fois qu'une base de code dépasse la hauteur de l'écran.
Weberc2

5
@ weberc2, pourriez-vous fournir des DOI à ces documents de recherche?
Grzegorz Adam Kowalski

9

Réponse simple: qu'est-ce qui est plus facile à déboguer?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

Dans quel cas avez-vous diagnostiqué le problème en premier?

Je me moque bien de mes préférences personnelles (il existe de nombreux autres styles, y compris whitesmith et al.) Et je m'en moque bien ... tant que cela ne gêne pas ma capacité à lire le code et déboguer .

Pour ce qui est de l'argument "espace perdu", je ne l'achète pas: j'ai tendance à ajouter des lignes vides entre les groupes logiques pour clarifier le programme ...


1
Ils sont aussi faciles à déboguer qu’il s’agit d’un court bloc de code. L'indentation est cohérente, ce qui facilite la visualisation des blocs de code réels.
Htbaa

@Htbaa: en effet :) Alors pourquoi s'embêter?
Matthieu M.

@MatthieuM. Le premier bloc a plus de sens pour moi, car les nouvelles lignes (dans le second bloc) entre la signature de la fonction, le for-statement et le if-statement me font croire qu'elles ne sont pas liées, mais elles ne le sont clairement pas. Les lignes vides doivent séparer des bits de code non liés; Un code proche des autres lignes de code signifie qu’elles sont en fait liées. Tout cela est "imo" bien sûr, mais je me demandais quel était votre point de vue. EDIT: tout IDE approprié remarquera également l’absence de support et vous donnera quelques erreurs lors de l’interprétation de votre code.
Klaar

7

Ce n’est pas que tout le monde le remarquera, mais c’est pourquoi les accolades même ligne que le conditionnel (sauf pour les très longs conditionnels, mais c'est un cas extrême):

En C, c'est une construction valide:

tandis que (vrai);
{
    char c;
    getchar (); // attendre l'entrée
}

Rapide! Que fait ce code? Si vous avez répondu "boucle infinie demandant l'entrée", vous vous trompez! Cela n'arrive même pas à l'entrée. Il se fait prendre à while(true). Remarquez ce point-virgule à la fin. Ce modèle est en réalité plus commun qu'il semble que cela devrait être; C vous oblige à déclarer vos variables au début d’un bloc, c’est pourquoi une nouvelle a été démarrée.

Une ligne de code est une pensée. Les accolades font partie de la pensée contenant le conditionnel ou la boucle. Par conséquent, ils appartiennent à la même ligne.


C’est de loin le meilleur argument que je connaisse pour le style K & R, le reste est risible avec les systèmes IDE actuels avec prise en charge du pliage de code. Cela ne s'applique qu'aux langages de style C qui prennent en charge ;les fins de bloc. C’est aussi la raison pour laquelle je méprise ce système de fin de bloc, dont le système de gestion de l’image à mon humble avis est dépassé et que le langage Go le prouve. J'ai vu ce problème plusieurs fois, mais pas dans ce scénario. Cela arrive généralement là où ils ont l'intention d'ajouter quelque chose à la déclaration et d'oublier de le faire.
Jeremy

5

J'aime la première méthode. Cela semble plus ordonné à l’OMI, et c’est plus compact, ce que j’aime.

EDIT: Ah, un troisième. J'aime celui-là le meilleur quand c'est possible, car il est encore plus petit / plus propre.


5

Vous pouvez l'écrire:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Pour répondre à la question; J'avais l'habitude de préférer les accolades sur leur propre ligne, mais, pour éviter de penser aux bugs liés à l'insertion automatique de points-virgules dans les navigateurs, j'ai commencé à utiliser le style égyptien pour javascript. Et lors du codage de java dans eclipse, je n'avais aucun intérêt à combattre (ou à configurer) le style d'accolade par défaut. Je suis donc allé dans ce cas avec Egyptian. Maintenant je vais bien avec les deux.


être utilisé comme ça, postAnswer()et doSomething()devrait renvoyer une valeur pour un opérateur ternaire, ce qui n’est souvent pas le cas: ils peuvent très bien renvoyer un vide (pas de valeur). et aussi (au moins en c #) résultat de ?:devrait être assigné à une variable
ASh

4

Presque toutes les réponses ici indiquent une variation sur "Quoi que vous fassiez, restez avec un ou deux".

Alors j'ai réfléchi un instant, et j'ai dû admettre que je ne le considère pas comme important. Quelqu'un peut-il honnêtement me dire que ce qui suit est difficile à suivre?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

Je ne suis sûr que de quelqu'un d'autre ... mais je n'ai absolument aucun problème à ce que je passe d'un style à un autre. Il m'a fallu quelques instants pour comprendre ce que le code faisait, mais c'est le résultat de ma saisie aléatoire de la syntaxe C-like. :)

À mon avis pas si humble, l'ouverture des accolades n'a presque pas d'importance pour la lisibilité du code. Il existe quelques exemples de cas énumérés ci-dessus où un style ou un autre fait une différence, mais dans la plupart des cas, l'utilisation judicieuse de lignes vierges permet de résoudre ce problème.

FWIW, nos styles de codage au travail utilisent une forme 1 légèrement plus structurée et une forme 3 modifiée. (C ++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

Je suis curieux de savoir si ceux qui préfèrent fortement la forme 2 trouveraient cette version de la forme 1 meilleure, simplement parce que la ligne vierge donne une séparation visuelle plus forte.


4
Comme le montre votre exemple, l'indentation est tellement importante que les accolades pour un code lisible. En fait, certaines langues font de l'indentation le seul moyen d'imbriquer des déclarations!

1
Ok, honnêtement, je trouve que votre exemple incohérent est difficile à lire. Pas vraiment difficile, mais plus difficile que si c'était cohérent.
Almo

Je suis d'accord avec Almo. Ce n'est pas un cas de "est-ce vraiment difficile". C'est un cas de "c'est vraiment plus dur", même si ce n'est pas difficile. Alors pourquoi rendre les choses plus difficiles? Dans les exemples de "jouets", les gens donnent bien sûr qu'il y a peu de différence. D'après mon expérience, lorsque j'hérite du code malveillant de quelqu'un d'autre et qu'il utilisait la méthode 1, il est souvent nécessaire d'aller de l'avant et de le transformer en méthode 2 pour pouvoir suivre la logique. Parce que cela devient souvent nécessaire; il répond automatiquement à la question de savoir quelle méthode est la meilleure et la plus facile à comprendre.
Dunk

@Dunk: Je ne peux pas imaginer un code qui serait sensiblement amélioré en échangeant de tels détails non pertinents.
jkerian

@ jkerian-Apparemment, vous n'avez pas hérité de beaucoup de code de la part d'autres personnes ayant longtemps quitté le projet ou la société. Je ne peux pas imaginer ne pas tomber dans cette situation de la part de personnes possédant plusieurs années d'expérience. Mais là encore, la situation de travail de chacun est différente. En outre, si vous devez effectuer des révisions de code "formelles", le formatage fait toute la différence. Être capable de lire le code naturellement est très important. Bien sûr, je peux faire une pause et penser à faire correspondre les accolades, mais cela ralentit le processus. Une façon ne nécessite pas de pause, les autres font. C'est pourquoi je ne vois pas pourquoi un autre choix pourrait être recommandé.
Dunk

4

Je suis surpris que cela n'ait pas encore été soulevé. Je préfère la deuxième approche car elle vous permet de sélectionner le bloc plus facilement.

Lorsque les accolades commencent et se terminent sur la même colonne et sur leur propre ligne, vous pouvez sélectionner dans la marge ou avec le curseur sur la colonne 0. Cela correspond généralement à une zone plus généreuse avec la sélection de la souris ou moins de frappes au clavier avec la sélection au clavier.

À l'origine, je travaillais avec des accolades sur la même ligne que le conditionnel, mais lorsque j'ai changé de poste, j'ai constaté que cela accélérait le rythme de travail. Ce n'est pas la nuit ni le jour bien sûr, mais c'est quelque chose qui vous ralentira légèrement lorsque vous travaillerez avec des attelles à côté de vos conditionnels.


Les vieux joueurs comme moi utilisent trois touches pour sélectionner le bloc, peu importe où se trouvent ces fichues accolades.
ergosys

2

Personnellement, j'aime la deuxième façon.

Cependant, ce que je vais démontrer est, à mon avis, meilleur car il en résulte une plus grande sécurité d'emploi! Un autre étudiant de mon université m'a demandé de l'aider à faire ses devoirs et voici à quoi ressemblait son code. Tout le programme ressemblait à un seul bloc. La chose intéressante est que 95% des bogues dans le programme qu'il a créé provenaient d'accolades mal assortis. L'autre 5% était évident une fois que les accolades ont été appariées.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);

8
Mauvais, mauvais, je veux dire terrible, exemple terrible. Le problème n'est pas les accolades! C'est l'indentation folle!
R. Martinho Fernandes

@Martinho Fernandes Je pensais que placer des accolades et une indentation vont de pair ...
AndrejaKo le

2
pas nécessairement ... faites l'indentation appropriée sur ce qui précède, puis modifiez de façon aléatoire les styles d'accolade, vous constaterez que c'est compréhensible.
Juin

En fait, penser à cela a motivé ma propre réponse à cette question.
jkerian

"95% des bogues dans le programme qu'il a créés provenaient d'accolades mal assortis" - uniquement dans des langages interprétés, non compilés.
Mawg

2

Ma préférence personnelle est pour la première méthode, probablement parce que c’est ainsi que j’ai appris le PHP.

Pour les ifdéclarations monolignes, je vais utiliser

if (you.hasAnswer()) you.postAnswer();

Si ce n'est pas you.postAnswer();quelque chose de plus long, comme you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);je reviendrai probablement au premier type:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Je n'utiliserai jamais de saut de ligne et je n'utiliserai jamais cette méthode s'il existe également une elsedéclaration.

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

est une possibilité théorique, mais je n'en aurais jamais utilisé. Cela devrait être transformé en

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

2

Ils ne devraient pas; première méthode pour moi.

Quand je regarde la seconde, à cause des lignes inutilisées (celles qui ont seulement des accolades, autres que la dernière accolade de fermeture), on a l'impression que cela brise la continuité du code. Je ne peux pas le lire aussi vite parce que je dois accorder une attention particulière aux lignes vides qui signifient généralement une séparation dans le but du code ou quelque chose du genre, mais en aucun cas "cette ligne appartient à une accolade" (qui ne fait que répéter le sens d'indentation).

Quoi qu’il en soit, tout comme lorsque vous écrivez du texte ... il est superflu d’ajouter une indentation au début d’un paragraphe si une ligne vierge le précède (double signe de changement de paragraphe), il n’est pas nécessaire de gaspiller des lignes pour des accolades. correctement indenté.

De plus, comme cela a déjà été dit, cela permet d’ajouter plus de code à l’écran, ce qui est sinon un peu contre-productif.


2

Cela dépend de la plate-forme / langue / conventions

En Java:

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

En C #

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

En C:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Je déteste quand les gars de Java utilisent leur style en code C # et vice versa.


3
Le style C m'a toujours agacé. Être cohérent!
Christian Mann

1

Tout ce que je peux dire, c'est que si vous êtes un fan de la méthode n ° 3, vous allez être persécuté par tous les formateurs de code IDE sur terre.


1

J'utilise la première méthode simplement parce qu'elle est plus compacte et permet plus de code à l'écran. Je n’ai moi-même jamais eu de problème pour jumeler des accolades (je les écris toujours avec leif instruction avant d'ajouter la condition, et la plupart des environnements vous permettent d'accéder à l'accolade correspondante).

Si vous avez besoin de jumeler des accolades visuellement, je préférerais la deuxième méthode. Cependant, cela permet moins de code à la fois, ce qui vous oblige à faire défiler davantage. Et cela, du moins pour moi, a un impact plus important sur la lecture du code que le fait d'avoir des accolades parfaitement alignées. Je déteste faire défiler. Là encore, si vous devez faire défiler une seule ifdéclaration, celle-ci est probablement trop volumineuse et nécessite une refactorisation.

Mais; la chose la plus importante est la cohérence. Utilisez l'un ou l'autre - jamais les deux!


0

Quand j’ai appris la programmation pour la première fois à 12 ans, j’ai mis les accolades à la ligne suivante parce que les tutoriels de codage Microsoft sont comme ça. J'ai également mis en retrait avec des onglets à 4 cases ce temps-là.

Après quelques années, j'ai appris Java et JavaScript, et j'ai vu plus de code entre accolades, alors j'ai changé. J'ai aussi commencé à mettre en retrait avec des espaces de 2 espaces.


5
+1, -1. Pourquoi ne PAS indenter avec des tabulations car tout éditeur peut ajuster la longueur de la tabulation à votre longueur arbitraire? Sinon, vous menez beaucoup d’entre nous qui aimons les véritables retraits à 8 pour maudire votre code.
Jé Queue

0

Il existe une 4ème option qui maintient les accolades alignées, mais ne gaspille pas d'espace:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

Le seul problème est que la plupart des autoformatteurs d'IDE s'étranglent à ce sujet.


9
... comme la plupart des programmeurs qui s'étoufferaient à ce sujet.
Jé Queue

4
Cela semble horrible. Pensez aux efforts supplémentaires que vous devez déployer si vous souhaitez insérer une ligne en haut ou en supprimer. Vous ne pouvez pas simplement supprimer la ligne et passer à autre chose, vous devez vous rappeler de réinsérer l'accolade.
Bryan Oakley

lol c'est génial! :) mieux que le premier style!
Nawfal

Apparemment, il a même un nom. Le Horstman Syyle est mentionné dans wikipedia . J'ai travaillé avec une base de code comme celle-ci, c'est vraiment pas mal à utiliser.
AShelly

-1

Tout dépend de vous tant que vous ne travaillez pas sur un projet pour lequel des contraintes de codage ou des normes ont été définies par le chef de projet que tous les programmeurs travaillant sur ce projet doivent suivre pendant le codage.

Personnellement, je préférerais la 1ère méthode.

Aussi, je n'ai pas compris ce que tu veux montrer avec la 3ème méthode?

N'est-ce pas une mauvaise façon? Par exemple, considérons une situation comme ..

if (you.hasAnswer())
  you.postAnswer();
else
  you.doSomething();

Maintenant, que se passe-t-il si quelqu'un veut ajouter d'autres déclarations dans le bloc if ?

Dans ce cas, si vous utilisez la 3ème méthode, le compilateur générera l'erreur de syntaxe.

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();

2
Le pire serait que quelqu'un vienne et fasse: if (you.hasAnswer ()) you.postAnswer (); sinon vous.douquelquechose (); you.doSomethingElse (); - c'est une recette pour des bugs subtils que l'oeil peut facilement glisser et que le compilateur ne va pas aider non plus
FinnNk

@FinnNk: Exactement!
Chankey Pathak

2
Si quelqu'un veut ajouter une autre déclaration, il peut mettre lui-même l'accolade. Tout programmeur digne de ce nom devrait pouvoir le savoir.
Robert Harvey

Je voulais dire que sa 3ème méthode est fausse.
Chankey Pathak

3
@ Robert Harvey, j'ai vu des codeurs très expérimentés ne pas ajouter les accolades lors de la modification du code existant. Je pense que le problème est que l'indentation est un indice de signification beaucoup plus puissant que les accolades (d'autant plus qu'il existe plusieurs styles d'accolades), il est donc assez facile d'oublier l'accolade manquante si l'indentation ressemble à ce que vous attendez.
AShelly
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.