Pourquoi l'omission des accolades est-elle considérée comme une mauvaise pratique ?

Question

Pourquoi tout le monde me dit qu'écrire du code comme ça est une mauvaise pratique ?

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

Mon principal argument en faveur de l'omission des accolades est qu'il y a parfois deux fois plus de lignes avec elles. Par exemple, voici du code pour peindre un effet lumineux pour une étiquette en C#.

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

Vous pouvez également bénéficier de l'avantage supplémentaire d'enchaîner usings sans avoir à faire des millions d'alinéas.

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

---

L'argument le plus courant en faveur des accolades tourne autour de la programmation de maintenance et des problèmes qui résulteraient de l'insertion de code entre l'instruction if originale et le résultat escompté :

if (foo)
    Bar();
    Biz();

---

Questions :

1. Est-ce une erreur de vouloir utiliser la syntaxe plus compacte qu'offre la langue ? Les personnes qui conçoivent ces langages sont intelligentes, je ne peux pas imaginer qu'elles mettraient une fonctionnalité qui est toujours mauvaise à utiliser.
2. Devons-nous ou ne devrions-nous pas écrire le code de manière à ce que le plus petit dénominateur commun puisse le comprendre et n'ait aucun problème à travailler avec lui ?
3. Y a-t-il un autre argument qui m'échappe ?

Answer 1

En fait, la seule fois où cela m'a vraiment fait mal, c'est lorsque je déboguais et que je commentais bar() :

if(foo)
  // bar();
doSomethingElse();

En dehors de cela, j'ai tendance à utiliser :

if(foo) bar();

Ce qui règle le cas précédent.

EDITAR Merci d'avoir clarifié la question, je suis d'accord, nous ne devrions pas écrire du code au plus petit dénominateur commun.

Answer 2

Vitesse de lecture...

En dehors de ce qui a déjà été mentionné. À ce stade, j'ai déjà été conditionné à analyser les instructions if avec des accolades et des espaces blancs. Donc je lis :

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Un peu plus rapide que ce que j'avais lu :

if (condition) DoSomething();

DoSomethingElse();

Je le lis un peu plus lentement si ça ressemble à ça :

if (condition) DoSomething();
DoSomethingElse();

Je l'ai lu beaucoup plus lentement que le précédent :

if (condition) 
    DoSomething();
DoSomethingElse();

parce que je ne peux pas m'empêcher de le relire juste au cas où et de me demander si l'auteur avait l'intention de le faire :

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

Déjà couvert en général, mais quand il s'agit de lecture Je vais examiner cette question pendant un certain temps pour m'assurer de l'intention de l'auteur. Je pourrais même retrouver l'auteur original pour confirmer.

if (condition) 
    DoSomething();
    DoSomethingElse();

Answer 3

Si c'est quelque chose de petit, écrivez-le comme ça :

if(foo()) bar();

S'il est suffisamment long pour être divisé en deux lignes, utilisez des accolades.

Answer 4

Je pensais aussi qu'il valait mieux n'utiliser un appareil dentaire que lorsque c'était vraiment nécessaire. Mais plus maintenant, la raison principale est que lorsque vous avez beaucoup de code, cela le rend plus lisible et vous pouvez analyser le code plus rapidement lorsque vous avez un style d'accolades cohérent.

Une autre bonne raison de toujours utiliser des accolades, outre le fait que quelqu'un ajoute une deuxième déclaration au if, est que quelque chose comme ceci pourrait se produire :

if(a)
   if(b)
     c();
else
   d();

Avez-vous remarqué que la clause else est en fait celle du "if(b)" ? Vous l'avez probablement fait, mais feriez-vous confiance à quelqu'un qui connaîtrait ce piège ?

Donc, juste par souci de cohérence et parce qu'on ne sait jamais ce qui peut arriver d'inattendu quand quelqu'un d'autre (ce sont toujours les autres qui sont stupides) change le code, je mets toujours des accolades, car cela rend le code source plus lisible, plus rapide à analyser par votre cerveau. Seulement pour les instructions if les plus simples, comme un if où une délégation est faite ou qui ressemble à un switch, où vous savez que la clause ne sera jamais étendue, je laisserais les accolades.

Answer 5

Je préfère la clarté qu'offre l'accolade bouclée. Vous savez exactement ce que vous voulez dire et vous n'avez pas à deviner si quelqu'un a simplement fait une gaffe en les omettant (et en introduisant un bogue). La seule fois où je les omets, c'est lorsque je place le if et l'action sur la même ligne. Je ne le fais pas très souvent non plus. En fait, je préfère l'espace blanc introduit en mettant l'accolade sur sa propre ligne, bien que, après des années de programmation K&R de type C, terminer la ligne par une accolade est une pratique que je dois travailler pour surmonter si l'IDE ne l'applique pas pour moi.

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}