Pourquoi est-il considéré comme une mauvaise pratique d'omettre les accolades? [fermé]

Pourquoi tout le monde me dit-il qu'écrire du code comme celui-ci est une mauvaise pratique?

if (foo)
    Bar();

//or

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

Mon plus grand argument pour omettre les accolades est qu'il peut parfois y avoir deux fois plus de lignes avec eux. Par exemple, voici du code pour peindre un effet d'éclat 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 obtenir l'avantage supplémentaire de chaîner usingsensemble sans avoir à indenter un million de fois.

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 pour les accolades tourne autour de la programmation de la maintenance et des problèmes qui en découleraient en insérant du code entre l'instruction if d'origine et son résultat attendu:

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

Des questions:

1. Est-il faux de vouloir utiliser la syntaxe plus compacte qu'offre le langage? Les gens qui conçoivent ces langages sont intelligents, je ne peux pas imaginer qu'ils mettraient une fonctionnalité toujours mauvaise à utiliser.
2. Devrions-nous ou ne devrions-nous pas écrire du code afin que le plus petit dénominateur commun puisse le comprendre et n'ait aucun problème à l'utiliser?
3. Y a-t-il un autre argument qui me manque?

En fait, la seule fois où je me suis vraiment mordu, c'était quand je déboguais et commentais bar ():

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

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

if(foo) bar();

Ce qui prend en charge le cas ci-dessus.

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

Vitesse de lecture ...

Hormis ce qui a déjà été mentionné. À ce stade, j'ai déjà été conditionné pour analyser les déclarations if avec des accolades et un espace blanc. Alors j'ai lu:

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Un peu plus vite que je ne l'ai lu:

if (condition) DoSomething();

DoSomethingElse();

Je le lis un peu plus lentement s'il ressemble à ceci:

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

J'ai lu ceci beaucoup plus lentement que le précédent:

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

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

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

Déjà couvert en général, mais quand il s'agit de lire ce qui suit, je vais examiner cela pendant un certain temps pour m'assurer de ce que l'auteur a voulu. Je peux même traquer l'auteur original pour confirmer.

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

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

if(foo()) bar();

S'il est assez long pour se diviser en deux lignes, utilisez des accolades.

J'avais aussi l'habitude de penser qu'il était préférable de n'utiliser des accolades qu'en cas de besoin. Mais plus maintenant, la principale raison, lorsque vous avez beaucoup de code, cela le rend plus lisible et vous pouvez analyser le code plus rapidement lorsque vous avez un style de contreventement cohérent.

Une autre bonne raison pour toujours utiliser des accolades, en plus de quelqu'un qui ajoute une deuxième instruction au if, est que quelque chose comme ça pourrait arriver:

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

Avez-vous remarqué que la clause else est en fait celle du "si (b)"? Vous l'avez probablement fait, mais feriez-vous confiance à quelqu'un pour être familier avec ce piège?

Donc, si juste pour la cohérence et parce que vous ne savez jamais quelles choses inattendues peuvent se produire 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 ton cerveau. Uniquement pour les déclarations if les plus simples, comme si une délégation est faite ou est de type interrupteur, où vous savez que la clause ne sera jamais étendue, je laisserais les accolades.

Cela n'est pas toujours considéré comme une mauvaise pratique. Les directives de codage des projets mono suggèrent de ne pas utiliser d'accolades si ce n'est pas nécessaire. La même chose pour les normes de codage GNU . Je pense que c'est une question de goût personnel, comme toujours avec les normes de codage.

Les lignes sont bon marché. La puissance du processeur est bon marché. Le temps du développeur est très coûteux.

En règle générale, à moins que je ne développe une application absolument critique en termes de ressources / vitesse, je me trompe toujours du côté de l'écriture de code qui est

(a) Facile pour tout autre développeur de suivre ce que je fais

(b) Commenter des parties spécifiques du code qui peuvent en avoir besoin

(c) Facile à déboguer en cas de problème

(d) Facile à modifier si cela doit être dans le futur (c.-à-d. ajouter / supprimer du code)

La rapidité ou l'élégance académique du code est secondaire à ces facteurs d'un point de vue commercial. Cela ne veut pas dire que je me suis mis à écrire du code maladroit ou laid, mais c'est MON ordre de priorité.

En omettant les accolades dans la plupart des cas, cela rend pour moi (b), (c) et (d) plus difficiles (notez cependant pas impossible). Je dirais que l'utilisation d'accolades ou non n'a pas d'effet sur (a).

Je préfère la clarté qu'offre l'accolade bouclée. Vous savez exactement ce que cela signifie et vous n'avez pas à deviner si quelqu'un a juste fait une gaffe et l'a laissé de côté (et a introduit un bogue). Le seul moment où je les omette, c'est lorsque je mets le if et l'action sur la même ligne. Je ne fais pas ça très souvent non plus. Je préfère en fait l'espace blanc introduit en mettant l'accolade sur sa propre ligne, bien que depuis des années de programmation de type K&R C, terminer la ligne avec une accolade est une pratique que je dois travailler pour surmonter si l'EDI ne l'applique pas pour moi.

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

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

Je pense que c'est une question de lignes directrices pour le projet sur lequel vous travaillez et de goût personnel.

Je les omets généralement lorsqu'ils ne sont pas nécessaires, sauf dans certains cas comme celui-ci:

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

je préfère

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}

L'un des cas où cela peut vous mordre est de retour dans l'ancien temps des macros C / C ++. Je sais que c'est une question C #, mais souvent les normes de codage sont reportées sans les raisons pour lesquelles la norme a été créée en premier lieu.

Si vous ne faites pas très attention lorsque vous créez vos macros, vous pouvez finir par causer des problèmes avec les instructions if qui n'utilisent pas {}.

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

Maintenant, ne vous méprenez pas, je ne dis pas que vous devriez toujours faire {} juste pour éviter ce problème en C / C ++, mais j'ai dû faire face à des bogues très étranges à cause de cela.

J'avais l'habitude de penser de la même manière.

Jusqu'au jour où (pourquoi y a-t-il toujours ce «jour» qui change votre vie pour toujours?) Nous passons de 24 à 36 heures d'affilée sans sommeil à déboguer le code de production uniquement pour découvrir que quelqu'un n'a pas mis d'accolades combiné avec un changement de recherche / remplacement .

C'était quelque chose comme ça.

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

Ce qui est venu après était

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

Il s'avère que le système générait 500 Mo de journaux par jour et on nous a demandé de l'arrêter. L'indicateur de débogage n'était pas suffisant, donc une recherche et un remplacement de println étaient en ordre.

Toujours lorsque l'application est entrée en production, l'indicateur de débogage était désactivé et l'important "saveDayData" n'a jamais été appelé.

ÉDITER

Maintenant, le seul endroit où je n'utilise pas les accolades est dans la construction if / try.

if( object != null ) try { 
     object.close();
} catch( .....

Après avoir regardé un développeur superstar faire cela.

Pour être franc, je le vois comme:

Les bons programmeurs programment de manière défensive, les mauvais programmeurs non.

Puisqu'il y a plusieurs exemples ci-dessus et mes propres expériences similaires avec des bugs liés à l'oubli des accolades, j'ai appris à la dure façon de TOUJOURS METTRE DES BRACELETS.

Tout le reste consiste à choisir un style personnel plutôt que la sécurité et c'est clairement une mauvaise programmation.

Joel mentionne même cela dans Making Wrong Code Look Wrong

Une fois que vous êtes mordu par un bogue à cause d'accolades manquantes, vous apprenez que les accolades manquantes ne semblent pas correctes parce que vous savez que c'est un endroit potentiel pour qu'un autre bogue se produise.

Je suis très heureux de:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

Personnellement, je ne vois pas pourquoi

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

est plus lisible.

Oui, les lignes sont gratuites, mais pourquoi devrais-je faire défiler les pages et les pages de code alors qu'il pourrait faire la moitié de la taille?

S'il y a une différence de lisibilité ou de maintenabilité, alors, bien sûr, mettez des accolades ... mais dans ce cas, je ne vois aucune raison de le faire.

De plus, je mettrai toujours des accolades pour les if imbriqués là où j'ai imbriqué les autres

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

contre

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

est terriblement déroutant, donc je l'écris toujours comme:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

Dans la mesure du possible, j'utilise des opérateurs ternaires, mais je ne les imbrique jamais .

Je conviens que "si vous êtes assez intelligent pour que quelqu'un vous paie pour écrire du code, vous devriez être assez intelligent pour ne pas vous fier uniquement à l'indentation pour voir le flux du code."

Cependant ... des erreurs peuvent être commises, et celle-ci est difficile à déboguer ... surtout si vous venez en regardant le code de quelqu'un d'autre.

Ma philosophie est que si cela rend le code plus lisible, pourquoi ne pas le faire?

De toute évidence, vous devez tracer la ligne quelque part, comme trouver le juste milieu entre les noms de variables concis et trop descriptifs. Mais les parenthèses évitent vraiment les erreurs et améliorent la lisibilité du code.

Vous pouvez affirmer que les gens assez intelligents pour être des codeurs le seront assez pour éviter les bogues qui provoquent des déclarations sans parenthèses. Mais pouvez-vous honnêtement dire que vous n'avez jamais été trébuché par quelque chose d'aussi simple qu'une faute d'orthographe? Des minuties comme celle-ci peuvent être accablantes lorsqu'on regarde de grands projets.

Il y a toujours des exceptions, mais je dirais contre l'omission d'accolades uniquement lorsque c'est dans l'une des formes:

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

Sinon, je n'ai aucun problème avec ça.

J'utilise occasionnellement le code le plus bas (plusieurs instructions using), mais à part cela, je mets toujours les accolades. Je trouve juste que cela rend le code plus clair. Il est manifestement évident, au-delà de la simple indentation, qu'une instruction fait partie d'un bloc (et donc probablement partie d'un if, etc.).

J'ai vu le

if (...)
    foo();
    bar();

bug m'a mordu (ou plutôt "moi et collègues" - je n'ai pas réellement introduit le bug) une fois . C'était en dépit du fait que nos normes de codage à l'époque recommandaient d'utiliser des accolades partout. Il m'a fallu un temps étonnamment long pour repérer - parce que vous voyez ce que vous voulez voir. (C'était il y a environ 10 ans. Peut-être que je le trouverais plus vite maintenant.)

Bien sûr, si vous utilisez "accolade à la fin de la ligne", cela réduit les lignes supplémentaires encourues, mais personnellement, je n'aime pas ce style de toute façon. (Je l'utilise au travail et je l'ai trouvé moins désagréable que prévu, mais c'est quand même un peu désagréable.)

Je suis impressionné et honoré que mes pairs dans ce domaine de la programmation informatique (vous beaucoup) ne soient pas découragés par la perspective de bogues potentiels lorsque vous sautez les accolades sur des blocs d'une seule ligne.

Je suppose que cela signifie que je ne suis pas intelligent. J'ai commis des erreurs à plusieurs reprises. J'ai débogué les erreurs des autres à ce sujet. J'ai regardé le logiciel livrer avec des bogues à cause de cela (RDP à une machine exécutant VS2002 et votre police de fenêtre de surveillance deviendra bancale).

Si je regarde toutes les erreurs que j'ai faites qui auraient pu être évitées avec un changement de style de codage, la liste est très longue. Si je n'avais pas changé mon approche dans chacun de ces cas, je ne l'aurais probablement jamais fait en tant que programmeur. Encore une fois, je suppose que je ne suis pas intelligent. Pour compenser, je suis un fervent utilisateur d'accolades sur des blocs à une seule ligne depuis longtemps.

Cela dit, certaines choses ont changé dans le monde qui rendent la règle "tu utiliseras des accolades sur des blocs à une seule ligne" moins pertinente aujourd'hui que lorsque Moïse nous l'a rapportée:

• Certains langages populaires font disparaître le problème en obligeant l'ordinateur à lire l'indentation, tout comme le fait le programmeur (par exemple Python).

• Mon éditeur formate automatiquement pour moi, donc les chances de me tromper par indentation sont beaucoup réduites.

• TDD signifie que si j'introduis un bogue parce que je suis confus par un bloc d'une seule ligne, je suis beaucoup plus susceptible de découvrir le bogue rapidement.

• Le refactoring et l'expressivité du langage signifient que mes blocs sont beaucoup plus courts et que les blocs sur une seule ligne se produisent beaucoup plus souvent que d'habitude. Hypothétiquement, avec une application impitoyable d'ExtractMethod, je pourrais peut-être n'avoir que des blocs d'une seule ligne dans tout mon programme. (Je me demande à quoi cela ressemblerait?)

En fait, il y a un avantage distinct à refactoriser sans pitié et à omettre les accolades sur les blocs à une seule ligne: quand vous voyez des accolades, une petite alarme peut se déclencher dans votre tête qui dit "complexité ici! Attention!". Imaginez si c'était la norme:

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

Je m'ouvre à l'idée de changer ma convention de codage en quelque chose comme "les blocs sur une seule ligne peuvent ne jamais avoir d'accolades" ou "si vous pouvez mettre le bloc sur la même ligne que la condition, et tout tient dans les 80 caractères, omettez les accolades ". Nous verrons.

Sur les trois conventions:

if(addCurleyBraces()) bugFreeSofware.hooray();

et:

if(addCurleyBraces())
    bugFreeSofware.hooray();

et (qui représentent n'importe quel style d'indentation utilisant une accolade ouvrante et fermante):

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

Je préfère le dernier comme:

• Je trouve qu'il est plus facile de lire si toutes les instructions if sont écrites de manière uniforme.
• Cela peut rendre le logiciel un peu plus robuste et sans bogue. Cependant, tous les IDE modernes et les éditeurs de texte avancés ont de jolies fonctionnalités d'indentation automatique que je pense que tout le monde devrait utiliser tant que cela ne gâche pas le formatage des commentaires ou ne va pas à l'encontre des normes de l'équipe (dans de nombreux cas, il est possible de créer un schéma de formatage personnalisé et partagez-le avec l'équipe). Mon point ici est que si l'indentation est effectuée correctement, le risque d'introduction de bogue est un peu réduit.
• Je préfère que l'expression booléenne et les instructions à exécuter soient sur des lignes différentes. J'aime pouvoir marquer une ligne à des fins de débogage. Même si j'utilise un IDE où je peux marquer une instruction et y accéder, c'est une opération interactive et je pourrais oublier où j'ai commencé à déboguer ou du moins il me faudra un peu plus de temps pour parcourir le code plusieurs fois (car je dois marquer la position manuellement à chaque fois pendant le débogage).

Vos principaux arguments contre l'utilisation d'accolades sont qu'ils utilisent des lignes supplémentaires et qu'ils nécessitent une indentation supplémentaire.

Les lignes sont (presque) libres, minimiser le nombre de lignes dans votre code ne devrait pas être un objectif.

Et l'indentation est indépendante de l'utilisation d'accolades. Dans votre exemple «d'utilisation» en cascade, je pense toujours que vous devriez les mettre en retrait même lorsque vous omettez les accolades.

Je crois fermement à l'écriture de code ordonné et concis, mais j'utiliserais toujours des accolades. Je trouve qu'ils sont un moyen pratique de voir rapidement la portée dans laquelle une ligne de code particulière existe. Il n'y a pas d'ambiguïté, c'est simplement exposé explicitement devant vous.

Certains peuvent dire que c'est un cas de préférence, mais je trouve le flux logique d'un programme beaucoup plus facile à suivre s'il est cohérent en interne, et je ne pense pas qu'il soit cohérent d'écrire une instruction IF comme celle-ci;

if(x < y)
    x = y;
else
    y = x;

Et un autre comme celui-ci;

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

Je préfère simplement choisir un style général et m'en tenir à lui :)

L' un des principaux problèmes est quand vous avez des régions d'une seule ligne et non un liners, ainsi que la séparation de la statment de commande ( for, if, qu'avez-vous) et la fin de la statment.

Par exemple:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}

J'étais un grand partisan de "les accolades sont un must!", Mais depuis l'adoption des tests unitaires, je trouve que mes tests unitaires protègent les déclarations sans accolades contre les scénarios comme:

if (foo)
    snafu();
    bar();

Avec de bons tests unitaires, je peux en toute confiance omettre les accolades pour les déclarations simples afin d'améliorer la lisibilité (oui, cela peut être subjectif).

Alternativement, pour quelque chose comme ce qui précède, je voudrais probablement que cela ressemble à:

if (foo) snafu();

De cette façon, le développeur qui a besoin d'ajouter bar () à la condition serait plus apte à reconnaître l'absence d'accolades et à les ajouter.

Faites preuve de jugement personnel.

if (foo)
  bar();

est très bien en soi. À moins que vous ne soyez vraiment inquiet que des crétins mettent quelque chose comme ça plus tard:

if (foo)
  bar();
  baz();

Si vous n'êtes pas inquiet pour les crétins, tout va bien (je ne le suis pas - s'ils ne parviennent pas à obtenir la syntaxe de base du code, c'est le moindre de leurs problèmes)>

En échange, c'est beaucoup plus lisible.

Le reste du temps:

if (foo) {
  bar();
  baz();
}

Ce qui a été mon préféré aussi longtemps que je me souvienne. Aditionellement:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

Travaille pour moi.

L'espace vertical en lui-même n'est pas très pertinent, la lisibilité l'est. L'accolade ouvrante sur une ligne arrête à elle seule la conversation pour un élément syntaxique, jusqu'à ce que votre œil se déplace vers la ligne suivante. Pas ce que j'aime.

D'accord, c'est une vieille question à laquelle on a répondu à mort. J'ai quelque chose à ajouter.

Tout d'abord, je dois juste dire UTILISER LES BRACELETS. Ils ne peuvent que contribuer à la lisibilité, et la lisibilité (pour vous-même et pour les autres!) Devrait être très élevée sur votre liste de priorité, sauf si vous écrivez l'assembly. Le code illisible conduit toujours à des bogues. Si vous trouvez que les accolades font prendre trop de place à votre code, vos méthodes sont probablement trop longues. La plupart ou la totalité des méthodes doivent tenir dans une hauteur d'écran si vous le faites correctement, et Find (F3) est votre ami.

Maintenant, pour mon ajout: il y a un problème avec ceci:

if (foo) bar();

Essayez de définir un point d'arrêt qui ne sera atteint que si bar () va s'exécuter. Vous pouvez le faire en C # en plaçant le curseur sur la seconde moitié du code, mais ce n'est pas évident et c'est un peu pénible. En C ++, vous ne pouviez pas du tout le faire. Un de nos développeurs les plus expérimentés travaillant sur du code C ++ insiste pour briser les instructions «if» en deux lignes pour cette raison. Et je suis d'accord avec lui.

Alors fais ceci:

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}

afin d'éviter que le code avec accolades ne prenne beaucoup de place, j'utilise la technique recommandée dans le livre Code Complete :

if (...) {
    foo();
    bar();
}
else {
    ...
}

Disons que vous avez du code:

if (foo)
    bar();

puis quelqu'un d'autre arrive et ajoute:

if (foo)
    snafu();
    bar();

Selon la façon dont il est écrit, bar (); est maintenant exécutée sans condition. En incluant les accolades, vous évitez ce genre d'erreur accidentelle. Le code doit être rédigé de manière à rendre ces erreurs difficiles ou impossibles à commettre. Si je faisais une revue de code et voyais les accolades manquantes, en particulier réparties sur plusieurs lignes, je créerais un défaut. Dans les cas où cela est justifié, conservez-le sur une seule ligne afin que les chances de commettre une telle erreur soient à nouveau réduites au minimum.

Réduire les lignes n'est pas vraiment un bon argument pour abandonner les accolades. Si votre méthode est trop volumineuse, elle devrait probablement être refactorisée en morceaux plus petits ou restructurée. Faire cela augmentera sans aucun doute la lisibilité plus que simplement retirer des accolades.

Je les omets toujours lorsque c'est approprié, comme dans votre premier exemple. Un code propre et concis que je peux voir et comprendre en jetant un œil est plus facile à maintenir, à déboguer et à comprendre que le code que je dois faire défiler et lire ligne par ligne. Je pense que la plupart des programmeurs seront d'accord avec cela.

Il est facile pour cela de devenir incontrôlable si vous commencez à faire plusieurs imbrications, clauses if / else et ainsi de suite, mais je pense que la plupart des programmeurs devraient être capables de dire où tracer la ligne.

Je vois un peu comme l'argument en faveur if ( foo == 0 )vs if ( 0 == foo ). Ce dernier peut éviter les bogues pour les nouveaux programmeurs (et peut-être même parfois pour les vétérans), tandis que le premier est plus facile à lire et à comprendre rapidement lorsque vous gérez du code.

La plupart du temps, il est enraciné en tant que norme de codage, que ce soit pour une entreprise ou un projet FOSS.

En fin de compte, quelqu'un d'autre devra grok votre code et c'est une perte de temps importante pour chaque développeur d'avoir à comprendre le style spécifique de la section de code sur laquelle il travaille.

Aussi, imaginez que quelqu'un passe entre Python et un langage Cish plus d'une fois par jour ... En Python l'indentation fait partie du bloc symantique du langage et il serait assez facile de faire une erreur comme celle que vous citez.

Optez pour une solution plus sécurisée - juste un autre bogue que vous n'aurez potentiellement pas à corriger.

Personnellement, je me sens plus en sécurité si tous mes blocs sont enveloppés dans des boucles. Même pour les one-liners, ce sont des notations simples qui évitent facilement les erreurs. Cela rend le code plus lisible dans le sens où vous voyez clairement ce qu'il y a dans le bloc pour ne pas confondre le corps du bloc avec les instructions suivantes en dehors du bloc.

Si j'ai un one-liner, je le formate généralement comme suit:

if( some_condition ) { do_some_operation; }

Si la ligne est trop encombrante, utilisez ce qui suit:

if( some_condition )
{
    do_some_operation;
}