Les accolades devraient-elles apparaître sur leur propre ligne? [fermé]
On février 14, 2021 by adminCommentaires
- Je trouve le " == true " plus distrayant que le choix de lemplacement des accolades.
- @Dan: Je pense que toujours expliquer lexpression conditionnelle aide grandement à la clarté.
- La seule raison pour laquelle cela serait ce serait si votre IDE / éditeur ne prend ' t prend en charge la reconnaissance des accolades correspondantes.
- @ leeand00: certains dentre nous impriment encore du code complexe / inconnu afin de létudier / lannoter. Une bonne jolie imprimante atténue la plupart des problèmes.
- Malheureusement, la question est close. Après un certain temps dutilisation de la syntaxe basée sur lindentation, je suis passé (peut-être bizarre) à une autre structure daccolades. Comme votre première accolade mais fermante dans la dernière ligne du bloc. (après la ligne de code)
Réponse
Quand jétais étudiant, javais lhabitude de mettre des accolades sur le même ligne, de sorte quil y ait moins de lignes et que le code soit imprimé sur moins de pages. Regarder un seul caractère entre crochets imprimé comme la seule chose dans une ligne est ennuyeux. (environnement, gaspillage de papier)
Mais lors du codage de grandes applications, autoriser certaines lignes avec seulement des accolades est abordable, compte tenu de la sensation de « regroupement » que cela donne.
Quel que soit le style que vous choisissez , soyez cohérent afin que cela ne devienne pas une surcharge pour votre propre cerveau de traiter plusieurs styles dans morceaux de code associés . Dans différents scénarios (comme ci-dessus), je dirais quil est normal dutiliser différents styles, il est plus facile de « changer de contexte » à un niveau élevé.
Commentaires
- Dun autre côté, laccolade sur la nouvelle ligne est une norme ANSI, K & R ne lest pas. Mais la beauté des normes est quil y en a tellement différents (voir aussi uncyclopedia.wikia.com/wiki/AAAAAAAAA ! sur uncyclopedia).
- " il y a moins de lignes " Jai des téraoctets despace et beaucoup de pixels. Pourquoi devrais-je me soucier dutiliser plus de lignes?
- @ 12431234123412341234123: I pense quil veut dire parce que certaines personnes impriment le code pour la révision du code. Et chaque nouvelle ligne non absolument nécessaire est du papier gaspillé, ou un kilomètre ² de forêt gaspillé à grande échelle. Cependant, si vous don ' t limprimer (je nai certainement pas ' t) alors ANSI est bien meilleur que K & R. De plus, quiconque a lintention dimprimer devrait probablement utiliser un formateur de code automatisé – donc cela devrait être une question doutillage, pas une question de style de codage.
- Je suis daccord que vous devez rester cohérent, je ' m utilise des accolades sur les nouvelles lignes depuis des années, mais je dois mélanger dans lautre sens dans mon code, comme lors de lappel de fonctions, de fonctions anonymes, de littéraux dobjet, etc. Tous les langages basés sur des expressions / code anonyme facilite grandement les crochets sur la même ligne
Réponse
Vous ne devriez jamais utiliser la 3ème méthode.
Lésiner sur les accolades peut vous éviter quelques frappes la première fois, mais le prochain codeur qui vient le long, ajoute quelque chose à votre clause else sans remarquer que le bloc est manquant daccolades va être très pénible.
Écrivez votre code pour dautres personnes.
Commentaires
- Jaimerais savoir doù vient ce petit peu de sagesse. Parce quécrire votre code pour les personnes qui ont gagné ' la peine de le lire est à peu près aussi inutile que possible …
- Le deuxième programmeur peut ajouter le sien accolades quand il ajoute quelque chose. Il ' nest pas stupide, et dans une convention de codage qui encourage lomission daccolades pour des choses simples comme celle-ci, il ' saura regarder.
- Les accolades facultatives ne sont pas facultatives. Il y a peu de pires décisions de conception qui ont été prises en C et transmises à ses descendants. Le fait quil vive dans un langage aussi récent que C # me fait rage.
- Cela ' na pas dimportance à quel point vous êtes intelligent ou à quel point la norme de codage enracinée autour des boucles omises sur une seule ligne est: si vous ' Si vous cherchez à résoudre un problème ou un bogue, vous manquerez probablement que les boucles ont été omises. Et pour un total de 2 secondes de travail, est-ce vraiment si mal dêtre explicite?
- Il y a ' un avantage au style n ° 3 que vous ' tout est manquant: vous obtenez plus de code sur votre écran à la fois.
Réponse
Pendant longtemps, jai soutenu quils étaient de valeur égale, ou alors très proche de légalité que le gain possible en faisant le bon choix était bien, très inférieur au coût de discussion à ce sujet.
Être cohérent est important , cependant. Alors jai dit «retournons une pièce de monnaie et passons à lécriture du code.
Jai déjà vu des programmeurs résister à un changement comme celui-ci. Passer à autre chose! Jai changé plusieurs fois dans ma carrière. Jutilise même des styles différents dans mon C # et dans mon PowerShell.
Il y a quelques années, je travaillais dans une équipe (~ 20 développeurs) qui a décidé de demander saisissez, puis prenez une décision, puis appliquez-la sur toute la base de code. Nous aurions 1 semaine pour décider.
Beaucoup de gémissements & eye -roulant. Beaucoup de « jaime ma manière, parce que » cest mieux « mais pas de substance.
Alors que nous étudiions les subtilités de la question, quelquun a demandé comment traiter ce problème en accolade-sur-le -same-line style:
void MyFunction( int parameterOne, int parameterTwo) { int localOne, int localTwo }
Notez que ce nest pas immédiatement évident où la liste de paramètres se termine, et le corps commence. Comparez avec:
void MyFunction( int parameterOne, int parameterTwo) { int localOne, int localTwo }
Nous avons fait quelques lectures sur la façon dont les gens du monde entier avaient traité ce problème, et avons trouvé le modèle dajout dune ligne vide après louverture accolade:
void MyFunction( int parameterOne, int parameterTwo) { int localOne, int localTwo }
Si vous « allez faire une pause visuelle, vous pouvez aussi bien le faire avec une accolade. Ensuite, vos coupures visuelles deviennent cohérentes, elles aussi .
Edit : Deux alternatives à la solution « extra blank line » lors de lutilisation de K & R:
1 / Indentez les arguments de la fonction différemment du corps de la fonction
2 / Mettez le premier argument sur la même ligne que le nom de la fonction et aligner les autres arguments sur les nouvelles lignes sur 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 soutiens toujours que la cohérence est plus importante que d’autres considérations, mais si nous n’avons pas de précédent établi , puis accolade sur la ligne suivante est la voie à suivre.
Commentaires
- Pour info, je peux avoir lair dune personne raisonnable, mais je ' suis en fait un fou. Pour les blocs simples dune seule ligne, je nutiliserai ni accolades ni sauts de ligne, ce qui rend ' if (foo) bar () ' tout un ligne. Je mefforce de rendre mon code suffisamment simple pour quil ' ne pose pas de problème.
- Je suis venu ici pour poster exactement ceci. Des tonnes de personnes qui gardent laccolade ouvrante sur la même ligne la suivent avec une ligne vide (surtout au début des classes et des méthodes) car sinon, elle ' est difficile de séparer len-tête de classe / méthode du corps. Eh bien, si vous ' allez quand même utiliser une ligne supplémentaire, vous pouvez aussi bien y mettre laccolade et bénéficier de lavantage supplémentaire que lindentation est plus facile à voir.
- Je ' nai pas vu la ligne vide – Je ' m plus familier avec le double retrait des paramètres de MyFunction () quand ils ségarent sur une autre ligne.
- Décomposer les paramètres sur plusieurs lignes comme ça est exaspérant.
- Le paramètre de fonction " " largument est un hareng rouge. De toute évidence, les arguments doivent être à double intention. Pas de problème pour le distinguer du code suivant.
Réponse
Les règles cardinales sont:
- Suivez la norme de codage existante du projet.
- Sil ny a pas de norme de codage et que vous modifiez une base de code existante appartenant à quelquun dautre – soyez cohérent avec le style du code existant, peu importe combien vous laimez / ne laimez pas.
- Si vous travaillez sur un projet de terrain vert – discutez avec dautres membres de léquipe et parvenez à un consensus sur une norme de codage formelle ou informelle.
- Si vous travaillez sur un projet vert en tant que développeur unique, décidez-vous, puis soyez impitoyablement cohérent .
Même si vous navez aucune contrainte externe sur vous, il est préférable (IMO) de rechercher une norme de codage ou un guide de style existant (largement utilisé), et essayez de le suivre. Si vous roulez votre propre style, il y a de fortes chances que vous le regrettiez dans quelques années.
Enfin, un style qui est implémenté / implémentable en utilisant les vérificateurs de style et les formateurs de code existants est meilleur que celui qui doit être « appliqué » manuellement.
Commentaires
- Cette réponse mérite plus de votes.
- cohérence est la clé
Réponse
Lavantage de la première méthode est quelle est plus compacte verticalement , vous pouvez donc insérer plus de code sur votre écran, et c’est pourquoi je le préfère. Le seul argument que j’ai entendu en faveur de la deuxième méthode est qu’elle facilite l’appariement des crochets ouvrants et fermants, mais la plupart des IDE ont un raccourci clavier pour cela, et cest en fait une fausse déclaration – au lieu de jumeler une parenthèse ouvrante à une parenthèse fermante, vous pouvez associer une parenthèse fermante à lexpression « début de bloc » (if, else, for, while) sur le même niveau dindentation, il est donc tout aussi facile à 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 for / while / if précédente indique déjà visuellement le début dun bloc.
Cela dit, je pense que le crochet fermant doit être dans sa propre ligne car nous avons besoin de quelque chose pour indiquer la fin dun bloc et sa structure dindentation de manière visible.
Commentaires
- Non … Je ' dis pourquoi réduire la quantité de code qui peut sadapter à votre écran en faisant quelque chose qui ne ' t ajouter au code ' la clarté?
- Quand je commençait à coder Jaimais chaque accolade sur sa propre ligne, maintenant je préfère la première méthode
- Il y a un énorme corpus de recherche, qui remonte au début de lère Steam (Weinberg, " Psychologie de la programmation informatique "), qui montre que la compréhension du programmeur diminue DRAMATIQUEMENT lorsque la quantité de code à afficher est supérieure à une fois (c.-à-d. une page décran, une page dimprimante). Ce phénomène plaide FORTEMENT pour considérer lespace vertical comme une ressource précieuse, à ne pas gaspiller gratuitement, et donc la première méthode est préférée.
- LOL @ " gaspiller un TOUTE la ligne ". OMG! Pas ça!! = P
- @Julio Au collège, jai fortement privilégié la méthode 1 et je nai pas pu ' lire la méthode 2. Après avoir travaillé dans une entreprise qui utilise C # , où la norme est la méthode 2, je ' en est venu à aimer cela aussi. Je peux maintenant lire ou utiliser lun ou lautre; ni lun ni lautre ne me dérange. Les personnes qui ont une réaction fortement opposée à lun ou à lautre réagissent généralement de manière excessive à quelque chose quelles ne connaissent pas.
Réponse
Je préfère
if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); }
plutôt que
if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); }
car la ligne you.postAnswer();
est beaucoup plus facile à lire et à trouver au premier coup dœil. Dans un second temps, il se fond dans la ligne au-dessus (you.hasAnswer()
), ce qui oblige mes yeux à se concentrer davantage pour le lire.
Commentaires
- Ceci est vrai jusquà ce que votre programme dépasse la hauteur de votre écran. 😉
- @ weberc2 Je pense que lorsque votre programme dépasse la hauteur de lécran, deux lignes en moins gagnent ' t changent beaucoup.
- Je nai jamais pu comprendre pourquoi jai préféré cette méthode mais elle ' s pour exactement ceci.
- @Mageek Ceci est tardif, mais ' nest pas 2 lignes, il ' s 2 lignes pour chaque portée. Cela ' est O (N), pas O (1). Je nai ' que je suis vraiment convaincu de cela; il ' est plus important que vous choisissiez un style qui rend les longues listes de paramètres lisibles.
i il y a plus de 10 ans, jaurais convenu de lespace à lécran. Aujourdhui, jutilise un écran 1920 * 1200. Cela correspond à BEAUCOUP de code, plus que mon cerveau ne peut en traiter à la fois. La première méthode me permet de reculer et de voir louverture / la fermeture de différentes portées sans avoir à la lire.
Réponse
Je préfère la première méthode. Les accolades ne valent pas la peine dêtre séparées.
Le fait est que les accolades ne sont pas importantes. Ils « ne sont que poubelle syntaxique , ce qui est absolument inutile pour comprendre à quoi sert le code, son but et son Cest juste un hommage aux langages de type C à lancienne 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 sont OK sans accolades du tout. Cela confirme seulement que les accolades sont des ordures et ne devraient pas mériter une ligne pour elles lorsque cela est possible:
if (you.hasAnswer()){ you.postAnswer(); }else{ you.doSomething(); }
Commentaires
- Je ne ' ne connais pas Haskell ou Ruby, mais Python est sensible aux espaces, cest pourquoi il ne nécessite ' des accolades ou dautres délimiteurs pour désigner les blocs. Les accolades ne sont pas seulement du bruit syntaxique; ils servent un but réel.
- @Robert, En C, vous devez faire à la fois des espaces et des accolades. En Python, vous ne devez faire que des espaces. Quel est le meilleur?
- @Pavel, en C ' vous n’avez pas ' à faire des espaces blancs.
- Les programmes @KenBloom C sans espace sont impossibles à lire. Donc, vous devez les faire quand même.
- Que les accolades soient une bonne idée ou non, la simple existence de langages qui ' ne les utilise pas ' t semble être un argument pour ou contre eux. Cela suggère seulement quil est possible davoir une langue sans eux, pas quil sagit dune conception de langage bonne ou mauvaise.
Réponse
Utilisez Python et évitez complètement largument.
Commentaires
- +1
SyntaxError: not a chance
- Ce nest tout simplement pas une option pour la très grande majorité des projets. De plus, lindentation pour le regroupement a sa part de problèmes '.
- @Bryan, je me rends compte que ce nest pas ' t très pratique. Je pensais juste que cétait un point de vue qui devait être là-bas, plus fort quun simple commentaire. Et je ' nai jamais rencontré les problèmes causés par lindentation que vous sous-entendez, probablement parce que je ne ' pas mélanger les tabulations et les espaces.
- Utilisez Go et évitez complètement largument (plus le typage statique, la vitesse et un compilateur!) 🙂
- Ensuite, appuyez trop de fois sur la barre despace et regardez le compilateur / interprète rire à toi. Cela ne se produira ' dans la plupart des langues accolées.
Réponse
La position des accolades doit être
meta data
configurable dans lIDE par le programmeur. De cette façon, ces accolades embêtantes dans tout le code, quel que soit lauteur, se ressemblent.
Commentaires
- Tout à fait daccord. Cest la présentation de ' et non les données.
- Le problème est que si vous laissez tout le monde définir le sien, les choses se compliquent très rapidement à mesure que les commits sont effectués.
- @Andy: Que ' est exactement le point, lEDI changera leur apparence, mais uniquement dans lEDI! La source réelle ne sera pas touchée. Pour le contrôle de version, vous pouvez ajouter des hooks qui traduisent le paramètre des accolades dans une situation courante, afin que tout le monde vérifie le code de la même manière.
- @klaar Chaque IDE moderne i ' ve utilisé changera les tabulations en espaces et déplacera les accolades vers leur propre ligne ou la fin de louverture " " ligne; Je ' ne sais pas pourquoi vous pensez que la source nest pas ' touchée dans ces cas, et cest la raison de mon commentaire. Il est généralement modifié par les IDE en fonction des paramètres du développeur, ce qui signifie que lors dun commit, je ' verrai beaucoup de changements qui ne sont que du bruit lorsque les accolades ont été déplacées vers leur propre ligne, cachant ainsi le changement ACTUEL que quelquun a fait.
- @Andy: Isn ' t-il la possibilité dutiliser des crochets qui convertissent ces écarts concernant les espaces et les accolades en un standard uniforme uppon commit, pour contourner le problème de bruit que vous avez décrit? Dans tous les cas, un système de contrôle de version approprié devrait transcender les choses insignifiantes comme les espaces ou autres choses insensées.
Réponse
Je préfère le premier car il mest plus difficile de voir lerreur dans cet exemple.
if (value > maximum); { dosomething(); }
que dans cet exemple
if (value > maximum); { dosomething(); }
Le ; {
me semble plus faux quune ligne se terminant par ;
donc je « suis plus susceptible de le remarquer.
Commentaires
- Vous faites un bon argument, mais personnellement, cela n’a jamais été mest arrivé une fois au cours de mes 5 années de programmation. Je ne pouvais ' comprendre pourquoi il nétait pas ' t en cours dexécution, je lai posté sur SO et quelquun ma rapidement fait remarquer le point-virgule. Cependant, chaque fois quil est condensé pour utiliser cette ligne de moins, je trouve que cest plus difficile à lire.
- Le "; {" ressemble à un sorte de visage grincheux clignotant ou peut-être une personne avec une moustache.
- +1 Excellent exemple de réponse: erreur très subtile, facilement négligée. Pensée provocante aussi sur la mise en page montrant cela.
- Bien sûr, tout IDE décent signalera linstruction de contrôle vide et tout compilateur décent émettra un avertissement.
- @Dunk La seule faille dans votre argument (avec lequel je suis fermement daccord) est que tant de personnes utilisent des langages interprétés ces jours-ci (JavaScript, PHP, et al) que beaucoup de " programmeurs " ne ' ne connaîtrait pas un compilateur à partir dun double latte.
Réponse
Cela dépend.
Si je code en Javascript ou jQuery, jutilise la première forme:
jQuery(function($) { if ($ instanceOf jQuery) { alert("$ is the jQuery object!"); } });
Mais si je code en C #, jutilise la deuxième forme, car cest la manière 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 #.
Commentaires
- Cela peut être écrit dans beaucoup de langages comme ça, car une instruction de bloc est une déclaration. Ajouter! 🙂
- Conformément aux " Directives de conception du cadre " les " manière canonique " est de placer laccolade ouvrante sur la même ligne (cest-à-dire la première forme). Dites simplement ' …
- @Uwe: Peut-être. Mais Microsoft a adopté lapproche " accolades alignées " pour tous ses exemples MSDN C #, et ' est intégré dans Visual Studio, donc …
- @Uwe: That ' s Cwalina ' s livre et il ' est terriblement nommé car il est bien plus que cela. Le FDG sur MSDN na rien à dire à ce sujet. Je me demande aussi pourquoi les directives relatives au Framework Design disent quelque chose sur la pratique du C # codage ?
- Vous devriez, en fait, 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/…
Réponse
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 quune certaine quantité de code source sur mon écran. Le style Bracket 2) rend les algorithmes heave avec beaucoup de boucles imbriquées et conditionnelles douloureusement longues.
-
Cependant, je veux que
else
commence sur une nouvelle ligne carif
etelse
vont ensemble, visuellement. Sil ya « une parenthèse devant leelse
, il est beaucoup plus difficile de repérer ce qui appartient à quoi. -
3 ) se disqualifie. Nous savons tous ce que de mauvaises choses peuvent arriver si vous laissez de côté les crochets et oubliez cela.
Commentaires
- Jai vu celui-ci là où je travaille. Cest ' intéressant.
- Jaime aussi mieux ce style, car il me permet de mettre un commentaire au-dessus de
else
ligne si nécessaire, et / ou mettre une ligne vide entre le bloc if et le bloc else pour que les choses paraissent moins encombrées. Le style de parenthèse n ° 2 ne fait rien dautre que déloigner les actions des conditions. Cela dit, mon préféré est définitivement python ' s sans crochet 🙂 - Sil est important de maximiser le nombre de lignes de code à lécran, supprimez-le avec des nouvelles lignes au total. Vous ' pourrez obtenir un grand nombre de lignes sur un seul écran. Je préfère ne rien avoir de me faire faire une pause et réfléchir pendant la lecture, cest à dire. 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.
- Oui, si et sinon vont ensemble, MAIS ainsi faites {et} et comme} est sur une ligne séparée, {devrait être sur une autre ligne, aussi. " Je ne peux insérer quune certaine quantité de code source sur mon écran " Et que ' Cest exactement pourquoi dire le 3) serait " se disqualifiant " nest pas du tout une option. Après une décennie de travail avec 3), je nai jamais oublié dajouter des crochets lors de lajout dune nouvelle ligne de code, et je ne connais personne qui lait jamais fait. Si je dois adapter le code à des personnes, qui ne peuvent ' t lire correctement, où se termine-t-il? Arrêter dutiliser certaines fonctionnalités linguistiques, car certains des lecteurs de codes peuvent ne pas les comprendre?
Réponse
Jai lu quelque part que les auteurs dun livre voulaient que leur code soit formaté comme ceci:
if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); }
Mais les contraintes despace de leur éditeur signifiaient quils devaient utiliser ceci:
if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); }
Maintenant, je ne sais pas si cest vrai (car je ne peux plus le trouver), mais ce dernier style est très répandu dans les livres.
Sur un plan personnel, je préfère les parenthèses sur un ligne séparée comme:
a) ils indiquent une nouvelle portée
b) cest plus facile à repérer lorsque vous avez une discordance (bien que ce soit moins un problème dans un IDE qui met en évidence les erreurs pour vous).
Commentaires
- … La deuxième option facilite également vos deux points (avec lindentation seule servant le but de laccolade / indentation combo). 🙂
Réponse
Ah, le One True Brace Style .
Il a tout ce quil faut pour un Holy W oui – même un prophète (Richard « à ma façon ou sur lautoroute » Stallman).
Le gars avait tellement tort sur tant de choses, mais GNU est parfait en ce qui concerne les accolades.
[Mise à jour] Jai vu la lumière, et maintenant adore Allman
Commentaires
- Je ne ' voir le point du style GNU, autre que le modèle de code lisp. Cela semble être beaucoup de travail pour peu davantages.
- Je ne connais personne qui utilise le style GNU. 1 To jusquau bout.
- Vous pouvez ' t faire pire que deux niveaux dindentation par bloc, sauf pour le style lisp, bien sûr, cela va sans dire.
- +1 pour le lien sur les styles daccolades. Cela montre que quel que soit votre style, de nombreuses personnes formidables ne sont pas daccord avec vous.
- @RobertHarvey Il ny a pas de travail supplémentaire, si cest le cas, vous ' nutilisez pas bon outil pour écrire du code ou le configurer correctement. Lavantage est un code beaucoup plus lisible, vous voyez toutes les erreurs dans le crochet très rapidement et vous pouvez facilement lire uniquement le code tout en ignorant les sous-blocs.
Réponse
Deuxième exemple, je « suis très grand sur la lisibilité. Je ne supporte pas de regarder si bloque autrement = (
Commentaires
- La recherche indique que ' est un code compact plus facile à lire une fois quune base de code dépasse la hauteur de lécran.
- @ weberc2 , pourriez-vous fournir des DOI à ces documents de recherche?
Réponse
Réponse simple: quest-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 ne me soucie pas beaucoup des préférences personnelles (il y en a beaucoup dautres styles, y compris whitesmith et al.) et je ne me soucie pas beaucoup … tant que cela ne gêne pas ma capacité à lire le code et déboguer it.
A s à largument « espace perdu », je ne lachète pas: jai tendance à ajouter des lignes vides entre les groupes logiques de toute façon pour rendre le programme plus clair …
Commentaires
- Ils sont tous les deux aussi faciles à déboguer, principalement car ' est un petit bloc de code. Lindentation est cohérente, ce qui facilite la visualisation des blocs de code réels.
- @Htbaa: en effet 🙂 Alors pourquoi sembêter?
- @MatthieuM. Le premier bloc a plus de sens pour moi, car les nouvelles lignes (dans le deuxième bloc) entre la signature de la fonction, linstruction for et linstruction if me font croire quelles ne sont pas liées, mais elles ne sont clairement pas ' t. Les lignes vierges doivent séparer les bits de code non liés; code que ' est proche dautres lignes de code signifie quelles sont en fait liées. Tout cela est bien sûr ' imo ', mais je me suis demandé quel était votre point de vue. EDIT: également tout IDE approprié remarquera toute accolade manquante et vous donnera une poignée derreurs lors de linterprétation de votre code.
- Je voudrais souligner que ces deux sections de code sont complètement différentes. Vous auriez des erreurs de compilateur à différents points du code. Le premier aurait une erreur de compilation sur " else " et le dernier bouclé. Le second naurait quune erreur de compilation sur le dernier bouclé.
Réponse
Personne ne le remarquera, mais cest pourquoi les accolades appartiennent à la même ligne que le conditionnel (sauf pour les conditionnelles très longues, mais cest une arête case):
En C, cest une construction valide:
while(true); { char c; getchar(); //Wait for input }
Rapide! Que fait ce code? Si vous avez répondu » boucle infinie demandant une entrée « , vous vous trompez! Elle ne parvient même pas à lentrée. Il est intercepté à while(true)
. Notez ce point-virgule à la fin.Ce modèle est en fait plus courant quil semble quil devrait lêtre; C vous oblige à déclarer vos variables au début dun bloc, cest pourquoi une nouvelle a été lancé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.
Commentaires
- Cest de loin le meilleur argument pour le style K & R que jai vu, le reste est risible avec aujourdhui ' s systèmes IDE avec support de pliage de code. Cela ne sapplique quaux langages de style C qui prennent en charge les fins de bloc
;
. Cest aussi pourquoi je méprise ce système de fin de bloc dont IMHO est obsolète et le langage Go le prouve. Jai vu ce problème plusieurs fois, mais pas dans ce scénario. Cela se produit généralement là où ils ont lintention dajouter quelque chose à la déclaration et doublier de le faire.
Réponse
Jaime le première méthode. Il semble plus soigné IMO, et il est plus compact, ce que jaime.
EDIT: Ah, un troisième. Jaime celui-là le meilleur quand possible, car il est encore plus petit / plus net.
Réponse
Vous pouvez lécrire:
you.hasAnswer() ? you.postAnswer() : you.doSomething();
À répondre à la question; Javais lhabitude de préférer les accolades sur leur propre ligne, mais, pour éviter davoir à penser aux bogues de linsertion automatique de points-virgules dans les navigateurs, jai commencé à utiliser le style égyptien pour javascript. Et lors du codage de java dans eclipse, je navais aucun intérêt à combattre (ou à configurer) le style daccolade par défaut, alors je suis allé avec Egyptian dans ce cas aussi. Maintenant, je « vais bien avec les deux.
Commentaires
- à utiliser comme ça,
postAnswer()
etdoSomething()
devrait renvoyer une valeur pour lopérateur ternaire, ce qui nest souvent pas le cas: ils peuvent très bien renvoyer void (pas de valeur). et aussi (au moins en c #) le résultat de?:
doit être attribué à une variable
Réponse
Presque toutes les réponses voici une variante de « Quoi que vous fassiez, tenez-vous-en à un ou deux ».
Jy ai donc réfléchi pendant un moment et jai dû admettre que je ne le vois pas comme si important . Quelquun 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 pas sûr de quelquun dautre … mais je nai absolument aucun problème mental basculer entre les styles. Il ma fallu quelques instants pour comprendre ce que faisait le code, mais cest le résultat de ma saisie aléatoire de syntaxe de type C. 🙂
À mon avis pas si humble, les accolades ouvrantes sont presque totalement sans rapport avec la lisibilité du code. Il y a quelques cas dangle énumérés ci-dessus où un style ou lautre fait une différence, mais pour la plupart, lutilisation judicieuse de lignes vides nettoie cela.
FWIW, nos styles de codage au travail utilisent un peu forme 1 plus structurée et 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 mieux, juste parce que la ligne vide donne une séparation visuelle plus forte.
Commentaires
- Comme le montre votre exemple, lindentation est tellement importante que les accolades pour la lecture code. En fait, certains langages font de lindentation le seul moyen dimbriquer des instructions!
- 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.
- Je suis daccord avec Almo. Ce nest pas un cas de " est-ce vraiment difficile " . Cest un cas de " cest définitivement plus difficile ", même si ce nest pas difficile. Alors pourquoi rendre les choses plus difficiles? Dans les exemples de " toy " que les gens donnent bien sûr, il y a peu de différence. Daprès mon expérience, lorsque jhérite du code désagréable de quelquun dautre et quils ont utilisé la méthode 1, il devient assez souvent nécessaire daller de lavant et de le transformer en méthode 2 juste pour pouvoir suivre la logique. En raison du fait 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: Je ne peux pas comprendre le code qui serait sensiblement amélioré en échangeant des détails non pertinents.
- @jkerian -Apparemment, vous navez ' hérité de beaucoup de code dautres personnes qui ont quitté depuis longtemps le projet ou lentreprise. Je ne peux ' t comprendre que personne avec quelques années dexpérience ne se heurte à cette situation. Mais là encore, la situation de travail de chacun ' est différente. De plus, 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. Un moyen ne nécessite pas de pause, les autres le font. Cest ' pourquoi je ne ' ne vois pas pourquoi tout autre choix pourrait être recommandé.
Réponse
Je suis surpris que cela nait pas encore été soulevé. Je préfère la deuxième approche car elle 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 à partir de la marge ou avec le curseur sur la colonne 0. Cela équivaut généralement à une zone plus généreuse avec sélection de la souris ou moins frappes avec sélection du clavier.
Au départ, jai travaillé avec des accolades sur la même ligne que le conditionnel, mais quand jai changé, jai trouvé que cela accélérait la vitesse à laquelle je travaillais. Ce nest pas la nuit et le jour bien sûr, mais cest quelque chose qui vous ralentira légèrement en travaillant avec des accolades à côté de vos conditions.
Commentaires
- Les anciens comme moi utilisent trois touches pour sélectionner le bloc, peu importe où se trouvent les foutues accolades.
Réponse
Personnellement, jaime la deuxième façon.
Cependant, la façon dont je vais vous montrer est à mon avis la meilleure parce quelle se traduit par une plus grande sécurité demploi! Un camarade de mon université ma demandé de laide pour ses devoirs et voici à quoi ressemblait son code. Lensemble du programme ressemblait à un seul bloc. La chose intéressante est que 95% des bogues dans le programme quil a créé provenaient daccolades incompatibles. Les 5% restants étaient évidents une fois que les accolades étaient 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);
Commentaires
- Mauvais, mauvais , Je veux dire un exemple terrible, terrible. Le problème, ce ne sont pas les accolades! Cest ' que lindentation folle!
- @Martinho Fernandes Je pensais que placer les accolades et lindentation vont de pair …
- pas nécessairement. .. faites une indentation appropriée sur ce qui précède, puis changez de style daccolade au hasard, vous ' trouvera que ' est compréhensible.
- En fait, réfléchir à cela a motivé ma propre réponse à cette question.
- " 95% des bogues du programme quil a créé provenaient accolades incompatibles " – uniquement dans les langues interprétées, non compilées.
Réponse
Ma préférence personnelle est pour la première méthode, probablement parce que cest comme ça que jai appris PHP pour la première fois.
Pour les instructions if
sur une seule ligne, Jutiliserai
if (you.hasAnswer()) you.postAnswer();
Si ce nest pas you.postAnswer();
mais quelque chose beaucoup plus longtemps, comme you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
je « reviendrai probablement au fi premier type:
if (you.hasAnswer) { you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType); }
Je nutiliserai jamais de saut de ligne, et je « nutiliserai jamais cette méthode sil » y a aussi un else
.
if (you.hasAnswer()) you.postAnswer(); else you.doSomething()
est une possibilité théorique, mais pas celle que jaurais jamais utilisée. Cela devrait être transformé en
if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); }
Réponse
Ils ne devraient pas; première méthode pour moi.
Quand je regarde la seconde, à cause des lignes inutilisées (celles qui nont que des accolades, à part la toute dernière accolade fermante), jai limpression quelle rompt la continuité de le code. Je ne peux pas le lire aussi vite car je dois porter une attention particulière aux lignes vides qui signifient généralement une séparation dans le but du code ou quelque chose comme ça, mais en aucun cas « cette ligne appartient à une accolade » (qui ne fait que répéter le sens dindentation).
De toute façon, tout comme lorsque vous écrivez du texte … lajout dune indentation au début dun paragraphe est superflu sil y a une ligne vide devant lui (double signe de changement de paragraphe), là il nest pas nécessaire de gaspiller des lignes pour les accolades lorsque nous sommes correctement indentés.
De plus, comme déjà indiqué, cela permet dajouter plus de code à lécran, ce qui est autrement un peu contre-productif.
Réponse
Cela dépend de la plate-forme / du langage / des 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 dans le code C # et vice versa.
Commentaires
- Le style C al les manières mennuyaient. Soyez cohérent!
Réponse
Tout ce que je peux dire, cest que si vous « êtes fan de la méthode n ° 3 , vous allez être persécuté par tous les formateurs de code IDE sur terre.
Réponse
Jutilise la première méthode simplement parce que il est plus compact et permet plus de code à lécran. Je nai moi-même jamais eu de problème avec lappairage des accolades (je les écris toujours, avec linstruction if
avant dajouter la condition , et la plupart des environnements vous permettent de passer à laccolade correspondante).
Si vous aviez besoin de jumeler visuellement des accolades, alors je préférerais la deuxième méthode. Cependant, cela permet moins de code à la fois, ce qui vous oblige à faire défiler plus. Et cela, du moins pour moi, a un plus grand impact sur la lecture du code que davoir des accolades parfaitement alignées. Je déteste le défilement. Là encore, si vous avez besoin de faire défiler une seule instruction if
, elle est probablement trop volumineuse et nécessite une refactorisation.
Mais; la chose la plus importante de toutes est la cohérence. Utilisez lun ou lautre – jamais les deux!
Réponse
Quand jai appris la programmation à 12 ans, jai mis les accolades la ligne suivante parce que les didacticiels de codage Microsoft sont comme ça. Jai également mis en retrait avec des TABS à 4 espaces cette fois-là.
Après quelques années, jai appris Java et JavaScript, et jai vu plus de code daccolades sur la même ligne, alors jai changé. Jai aussi commencé à mettre en retrait avec ESPACES à 2 espaces.
Commentaires
- +1, -1. Pourquoi ne pas mettre en retrait avec les tabulations car nimporte quel éditeur peut ajuster la longueur de tabulation à votre longueur arbitraire? Sinon, vous amenez beaucoup dentre nous qui aiment les vrais retraits à 8 à maudire votre code.
Réponse
Il existe une 4ème option qui garde les accolades alignées, mais ne gaspille pas despace:
if (you.hasAnswer()) { you.postAnswer(); i.readAnswer(); } else { you.doSomething(); }
Le seul problème est que la plupart des autoformateurs de lIDE sétouffent avec cela.
Commentaires
- … comme le font la plupart des programmeurs qui sétoufferaient avec ça.
- Cela semble horrible. Pensez au vous devez faire un effort supplémentaire si vous voulez insérer une ligne en haut ou supprimer la ligne du haut. Vous pouvez ' t simplement supprimer la ligne et continuer, vous devez vous en souvenir pour réinsérer laccolade.
- lol cest génial! 🙂 mieux que le premier style!
- Apparemment, il a même un nom. Le Horstman Syyle est mentionné dans wikipedia . Jai ' travaillé avec une base de code comme ceci, ' est vraiment pas mal de utiliser.
Réponse
Tout dépend de vous tant que vous ne travaillez pas sur un projet où certains des contraintes de codage ou certaines normes ont été définies par le chef de projet que tous les programmeurs qui travaillent sur ce projet doivent suivre lors du codage.
Personnellement, je préférerais la 1ère méthode.
Aussi je nai pas obtenu ce que vous voulez montrer par la troisiè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();
Et maintenant, que se passe-t-il si quelquun veut ajouter dautres instructions dans le if block?
Dans ce cas, si vous utilisez la 3ème méthode, le compilateur lancera lerreur de syntaxe.
if (you.hasAnswer()) you.postAnswer1(); you.postAnswer2(); else you.doSomething();
Commentaires
- Le pire serait encore si quelquun venait et faisait: if (you.hasAnswer ()) you.postAnswer (); sinon vous.doSomething (); you.doSomethingElse (); – cest ' une recette de bogues subtils que lœil peut facilement glisser et que le compilateur na ' pas aider non plus
- @FinnNk: Exactement!
- Si quelquun veut ajouter une autre instruction, il peut lui-même mettre entre accolades. Tout programmeur digne de ce nom devrait vraiment être capable de comprendre cela.
- Je voulais dire que sa troisième méthode est fausse.
- @Robert Harvey, I ' Jai vu des codeurs très expérimentés manquer dajouter les accolades lors de la modification du code existant. Je pense que le problème est que lindentation est un indice beaucoup plus fort de la signification que les accolades (dautant plus quil existe plusieurs styles daccolades), il est donc ' dignorer laccolade manquante si le lindentation ressemble à ce que vous attendez.
Laisser un commentaire