Les accolades doivent-elles apparaître sur leur propre ligne?
Les accolades devraient-elles être sur leur propre ligne 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();
Soyez constructif! Expliquez pourquoi, partagez vos expériences, étayez-les avec des faits et des références.
Quand j'étais étudiant, je mettais 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 seul caractère de parenthèse 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 uniquement des accolades est abordable, compte tenu du sentiment de "regroupement" que cela donne.
Quel que soit le style que vous choisissez, soyez cohérent afin qu'il ne devienne pas une surcharge pour votre propre cerveau pour traiter plusieurs styles dans 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.
Lésiner sur les accolades pourrait vous faire économiser quelques touches la première fois, mais le prochain codeur qui vient, ajoute quelque chose à votre clause else sans remarquer que le bloc est manquant, les accolades vont être très douloureuses.
Écrivez votre code pour d'autres personnes.
Pendant longtemps, j'ai soutenu qu'ils étaient de valeur égale, ou alors très proche de l'égalité que le gain possible en faisant le bon choix était loin, loin , en dessous du coût de discuter à ce sujet.
Être cohérent est cependant important . Alors j'ai dit jetons une pièce et passons à l'écriture de code.
J'ai déjà vu des programmeurs résister à de tels changements. Passer à autre chose! J'ai changé plusieurs fois de 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 sur une équipe (~ 20 développeurs) qui a décidé de demander des commentaires, puis de prendre une décision, puis de l'imposer sur toute la base de code. Nous aurions 1 semaine pour décider.
Beaucoup de gémissements et de roulement des yeux. Beaucoup de "j'aime ma façon, parce que c'est mieux" mais pas de substance.
Alors que nous étudiions les points les plus fins de la question, quelqu'un a demandé comment traiter ce problème dans un style accolade sur la même ligne:
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
Notez que la fin de la liste des paramètres n'est pas immédiatement évidente et que le corps commence. Comparer aux:
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 ont traité ce problème et avons trouvé le modèle d'ajout d'une ligne vierge après l'accolade ouverte:
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
Si vous allez faire une pause visuelle, vous pouvez aussi bien le faire avec un corset. Ensuite, vos pauses visuelles deviennent également cohérentes.
Edit : Deux alternatives à la solution 'ligne vierge supplémentaire' lors de l'utilisation de K&R:
1/Indenter les arguments de fonction différemment du corps de fonction
2/Placer le premier argument sur la même ligne que le nom de la fonction et aligner les autres arguments des 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 , alors l'accolade sur la ligne suivante est le chemin à parcourir.
Les règles cardinales sont les suivantes:
- Suivez la norme de codage existante du projet.
- 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/ne l'aimez pas.
- Si vous travaillez sur un projet écologique - discutez avec les autres membres de l'équipe et parvenez à un consensus sur une norme de codage formelle ou informelle.
- Si vous travaillez sur un projet vierge en tant que seul développeur - faites-vous votre propre opinion, puis soyez impitoyablement cohérent.
Même si vous n'avez pas de contraintes externes sur vous, il est (IMO) préférable de rechercher une norme de codage ou une directive de style existante (largement utilisée), et essayez de suivre cela. Si vous lancez 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 à l'aide de vérificateurs de style et de formateurs de code existants est meilleur que celui qui doit être "appliqué" manuellement.
L'avantage de la première méthode est qu'elle est plus compacte verticalement, vous pouvez donc insérer plus de code sur votre écran, et 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 facilite le couplage 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 de coupler un crochet d'ouverture à une fermeture parenthèse vous pouvez associer une parenthèse fermante à l'expression "début de bloc" (si, sinon, pour, pendant) au 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, je crois 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();
}
car la ligne you.postAnswer(); est beaucoup plus facile à lire et à trouver à première vue. Dans le deuxième cas, il se confond avec la ligne au-dessus (you.hasAnswer()) obligeant mes yeux à se concentrer davantage pour le lire.
Je préfère la première méthode. Les accolades ne valent absolument pas la ligne séparée.
Le fait est que les accolades ne sont pas importantes. Ils sont juste poubelle syntaxique, ce qui est absolument inutile pour comprendre à quoi sert le code, son but et la façon dont il est implémenté. Ils ne sont qu'un hommage aux langages de type C à l'ancienne où le regroupement visuel des opérateurs était impossible en raison du faible espace d'écran disponible.
Il existe des langages (Python, Haskell, Ruby) qui sont OK sans accolades du tout. Cela confirme seulement que les accolades sont des poubelles et ne devraient pas mériter une ligne pour elles dans la mesure du possible:
if (you.hasAnswer()){
you.postAnswer();
}else{
you.doSomething();
}
Utilisez Python et contournez complètement l'argument.
La position des accolades doit être
métadonnées
configurable dans le IDE par le programmeur. De cette façon, ces accolades embêtantes dans tout le code, quel que soit l'auteur, se ressemblent.
Je préfère le premier car il est plus difficile pour moi de voir l'erreur dans cet exemple.
if (value > maximum);
{
dosomething();
}
que dans cet exemple
if (value > maximum); {
dosomething();
}
Le ; { me semble plus faux qu'une ligne se terminant par ; donc je suis plus susceptible de le remarquer.
Ç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 la deuxième forme, car c'est 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 #.
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 placer qu'une certaine quantité de code source sur mon écran. Le style de parenthèse 2) rend les algorithmes de soulèvement avec beaucoup de boucles imbriquées et de conditions douloureusement longues.
Cependant, je veux que
elsedémarre sur une nouvelle ligne carifetelsevont ensemble, visuellement. S'il y a un crochet devant leelse, il est beaucoup plus difficile de repérer ce qui appartient à quoi.3) se disqualifie. Nous savons tous quelles mauvaises choses peuvent se produire si vous omettez les parenthèses et que vous les oubliez.
J'ai lu quelque part que les auteurs d'un livre voulaient que leur code soit formaté comme ceci:
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
Mais les contraintes d'espace de leur éditeur signifiaient 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 un plan personnel, je préfère les crochets sur une ligne distincte comme:
a) ils indiquent une nouvelle portée
b) il est plus facile de repérer lorsque vous avez un décalage (bien que ce soit moins un problème dans un IDE qui met en évidence les erreurs pour vous).
Ah, le One True Brace Style .
Il a tout pour une voie sainte - même un prophète (Richard "mon chemin ou l'autoroute" Stallman).
Le gars avait tellement tort sur tant de choses, mais GNU est parfait quand il s'agit d'accolades.
[Mise à jour] J'ai vu la lumière, et maintenant j'adore Allman
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 ne me soucie pas beaucoup des préférences personnelles (il existe de nombreux autres styles, y compris whitesmith et al.) Et je m'en fous beaucoup ... tant que cela n'entrave pas ma capacité à lire le code et débogage it.
Quant à l'argument "gaspillage d'espace", je ne l'achète pas: j'ai quand même tendance à ajouter des lignes vides entre les groupes logiques pour rendre le programme plus clair ...
Deuxième exemple, je suis très gros sur la lisibilité. Je ne supporte pas de regarder si les blocs d'une autre manière = (
Pas que quiconque le remarquera, mais c'est pourquoi les accolades appartiennent sur le même ligne comme conditionnel (sauf pour les très longs conditionnels, mais c'est un cas Edge):
En C, c'est une construction valide:
while (true);
{
char c;
getchar (); // Attendre l'entrée
}
Rapide! Que fait ce code? Si vous avez répondu "boucle infinie demandant une entrée", vous vous trompez! Il ne parvient même pas à l'entrée. Il est pris dans while(true). Notez ce point-virgule à la fin. Ce modèle est en fait plus courant qu'il semble qu'il devrait l'ê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. Il semble plus joli OMI, et il 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 pourriez 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 d'avoir à penser aux bugs de 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, alors j'ai opté pour l'égyptien dans ce cas également. Maintenant, je vais bien avec les deux.
Presque toutes les réponses ici disent une certaine variation sur "Quoi que vous fassiez, restez avec un ou deux".
Alors j'y ai réfléchi un instant et j'ai dû admettre que je ne le considère pas comme si 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 de personne d'autre ... mais je n'ai absolument aucun problème à basculer mentalement entre les styles. Cela m'a pris quelques instants pour comprendre ce que le code a fait, mais c'est le résultat de ma saisie aléatoire de la syntaxe de type C. :)
À mon avis, pas si humble, les accolades ouvrantes ne sont presque pas pertinentes pour la lisibilité du code. Il y a quelques cas d'angle répertoriés ci-dessus où un style ou l'autre fait la différence, mais pour la plupart, une utilisation judicieuse des lignes vides nettoie cela.
FWIW, nos styles de codage au travail utilisent une forme 1 légèrement plus structurée et une forme modifiée 3. (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 seconde approche car elle permet de sélectionner plus facilement le bloc.
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 équivaut généralement à une zone plus généreuse avec la sélection de la souris ou moins de frappes avec la sélection du clavier.
À l'origine, je travaillais avec des accolades sur la même ligne que le conditionnel, mais lorsque j'ai changé, j'ai trouvé que cela accélérait la vitesse à laquelle je travaillais. Ce n'est pas la nuit et le jour bien sûr, mais c'est quelque chose qui vous ralentira légèrement en travaillant avec des accolades à côté de vos conditionnels.
Ma préférence personnelle est pour la première méthode, probablement parce que c'est ainsi que j'ai appris PHP pour la première fois.
Pour les instructions if sur une seule ligne, je vais utiliser
if (you.hasAnswer()) you.postAnswer();
Si ce n'est pas you.postAnswer(); mais quelque chose de beaucoup plus long, comme you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType); je vais probablement revenir 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 y a aussi une instruction else.
if (you.hasAnswer()) you.postAnswer();
else you.doSomething()
est une possibilité théorique, mais pas celle que j'utiliserais jamais. Cela devrait être transformé en
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
Personnellement, j'aime la deuxième façon.
Cependant, la façon dont je vais démontrer est à mon avis la meilleure car elle permet une plus grande sécurité d'emploi! Un camarade de mon université m'a demandé de l'aide pour ses devoirs et voici à quoi ressemblait son code. L'ensemble du programme ressemblait à un seul bloc. La chose intéressante est que 95% des bogues dans le programme qu'il a créé provenaient d'accolades incompatibles. Les 5% restants étaient évidents une fois les accolades 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);
Ils ne devraient pas; première méthode pour moi.
Quand je regarde la seconde, à cause des lignes inutilisées (celles qui n'ont que des accolades, autre que la toute dernière accolade fermante), on a l'impression qu'elle rompt la continuité du code. Je ne peux pas le lire aussi vite parce que 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 d'indentation).
Quoi qu'il en soit, tout comme lorsque vous écrivez du texte ... l'ajout d'une indentation au début d'un paragraphe est superflu s'il y a une ligne vide devant (double signe du changement de paragraphe), il n'est pas nécessaire de gaspiller les lignes pour les accolades lorsque nous sommes correctement en retrait.
De plus, comme cela a déjà été dit, cela permet de placer plus de code à l'écran, ce qui est autrement 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 Java utilisent leur style en code C # et vice versa.
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 avec l'appariement d'accolades (je les écris toujours, avec l'instruction if avant d'ajouter la condition, et la plupart des environnements vous permettent de passer à l'accolade correspondante).
Si vous avez besoin d'appairer des accolades visuellement, 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, pour moi au moins, a un impact plus important sur la lecture de code que d'avoir des accolades parfaitement alignées. Je déteste le défilement. Là encore, si vous devez faire défiler une seule instruction if, elle est probablement trop volumineuse et doit être refactorisée.
Mais; la chose la plus importante de toutes est la cohérence. Utilisez l'un ou l'autre - jamais les deux!
Tout ce que je peux dire, c'est que si vous êtes un fan de la méthode # 3, vous allez être persécuté par tous les IDE formateurs de code sur terre.
Il existe une quatrième option qui maintient les accolades alignées, mais ne perd pas d'espace:
if (you.hasAnswer())
{ you.postAnswer();
i.readAnswer();
}
else
{ you.doSomething();
}
Le seul problème est que la plupart des formats automatiques d'IDE s'étouffent à ce sujet.
Quand j'ai commencé à apprendre la programmation à 12 ans, j'ai mis les accolades sur la ligne suivante parce que les tutoriels de codage Microsoft sont comme ça. J'ai également mis en retrait avec des tabulations à 4 espaces à cette époque.
Après quelques années, j'ai appris Java et JavaScript, et j'ai vu plus de code d'accolades sur la même ligne, j'ai donc changé. J'ai également commencé à indenter avec des espaces à 2 espaces.