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

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.

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é.

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.

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.

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.

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.

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.

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();
}

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

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.

Ç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 #.

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.

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.

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).

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

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 = (

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 ...

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.

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.

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.

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.

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.

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);

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();
}

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.

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.

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.

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!

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.

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.

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();