Pourquoi les énoncés «if elif else» ne sont-ils pratiquement jamais sous forme de tableau?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

CONTRE

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Compte tenu des exemples ci-dessus, je ne comprends pas pourquoi je ne vois pratiquement jamais le premier style dans les bases de code. Pour moi, vous transformez le code en un format tabulaire indiquant clairement ce que vous voulez. La première colonne peut être virtuellement ignorée. La deuxième colonne identifie la condition et la troisième colonne vous donne le résultat souhaité. Au moins, cela me semble simple et facile à lire. Pourtant, je vois toujours ce type de cas simple / commutateur apparaître dans le format étendu, en retrait. Pourquoi donc? Les gens trouvent-ils le deuxième format plus lisible?

Le seul cas où cela pourrait poser problème est si le code change et devient plus long. Dans ce cas, je pense qu'il est parfaitement raisonnable de reformuler le code dans le format long et en retrait. Est-ce que tout le monde fait la deuxième façon simplement parce que c'est toujours comme ça? Étant un avocat du diable, je suppose qu'une autre raison pourrait être que les gens trouvent que deux formats différents dépendant de la complexité des déclarations if / else créent de la confusion. Toute idée serait appréciée.

Une des raisons peut être que vous n'utilisez pas de langues où c'est populaire.

Quelques contre-exemples:

Haskell avec des gardes et avec des motifs:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Erlang avec des motifs:

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs lisp:

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

En général, je vois que le format de table est assez populaire avec les langages fonctionnels (et ceux basés sur l’expression en général), tandis que casser les lignes est plus populaire chez les autres (principalement à base d’instructions).

C'est plus lisible. Quelques raisons pour lesquelles:

• Presque toutes les langues utilisent cette syntaxe (pas toutes, la plupart - votre exemple semble être Python, cependant)
• isanae a souligné dans un commentaire que la plupart des débogueurs sont basés sur les lignes (pas sur les instructions)
• Cela commence à paraître encore plus moche si vous devez aligner des points-virgules ou des accolades
• Il se lit de manière plus fluide de haut en bas
• Il semble horriblement illisible si vous avez autre chose que des déclarations de retour triviales
  • Toute syntaxe significative de retrait est perdue lorsque vous parcourez du code, car le code conditionnel n'est plus séparé visuellement (de Dan Neely ).
  • Ce sera particulièrement grave si vous continuez à patcher / ajouter des éléments dans les instructions de 1 ligne si
• Ce n'est lisible que si toutes vos vérifications si sont à peu près de la même longueur
• Cela signifie que vous ne pouvez pas formater compliqué si les déclarations en déclarations multilignes, ils doivent être Citations
• Je suis beaucoup plus susceptible de remarquer des bugs / une logique en lisant verticalement ligne par ligne, sans essayer d'analyser plusieurs lignes ensemble
• Notre cerveau lit un texte plus étroit et plus large BEAUCOUP plus rapidement qu'un texte long et horizontal

À la minute où vous essayez de faire cela, vous finirez par le réécrire en plusieurs instructions. Ce qui signifie que vous venez de perdre du temps!

De plus, les gens ajoutent inévitablement quelque chose comme:

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Cela ne prend pas très souvent cela avant de décider que ce format est bien meilleur que votre alternative. Ah, mais vous pouvez tout aligner en une seule ligne! Enderland meurt à l'intérieur .

Ou ca:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

Ce qui est vraiment très ennuyant. Personne n'aime formater des choses comme ça.

Et enfin, vous allez commencer la guerre sainte du problème "combien d'espaces pour les onglets". Ce qui s'affiche parfaitement sur votre écran sous forme de tableau peut ne pas être rendu sur le mien en fonction des paramètres.

La lisibilité ne devrait de toute façon pas dépendre des paramètres IDE.

Je crois fermement que «le code est lu plusieurs fois, peu écrit - la lisibilité est donc très importante».

Un élément clé qui m'aide lorsque je lis le code d'autres personnes est de suivre les schémas «normaux» que mes yeux sont formés à reconnaître. Je peux lire la forme indentée plus facilement parce que je l’ai vue tellement de fois qu’elle s’enregistre presque automatiquement (avec peu d’effort cognitif de ma part). Ce n'est pas parce que c'est 'plus joli' - c'est parce que ça respecte les conventions auxquelles je suis habitué. La convention bat 'mieux' ...

Outre les autres inconvénients déjà mentionnés, la présentation tabulaire augmente les chances de conflits de fusion de contrôle de version nécessitant une intervention manuelle.

Lorsqu'un bloc de code aligné tabulairement doit être réaligné, le système de contrôle de version considérera chacune de ces lignes comme ayant été modifiée:

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

Supposons maintenant qu'entre temps, dans une autre branche, un programmeur a ajouté une nouvelle ligne au bloc de code aligné:

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

La fusion de cette branche échouera:

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

Si le code en cours de modification n'avait pas utilisé d'alignement tabulaire, la fusion aurait réussi automatiquement.

(Cette réponse a été "plagiée" de mon propre article décourageant l'alignement tabulaire dans le code).

Les formats tabulaires peuvent être très utiles si les choses s’intègrent toujours dans la largeur allouée. Cependant, si quelque chose dépasse la largeur allouée, il est souvent nécessaire de disposer d'une partie de la table qui n'est pas alignée avec le reste, ou bien d'ajuster la disposition de tout le reste de la table pour l'adapter à l'élément long. .

Si les fichiers source ont été modifiés à l'aide de programmes conçus pour fonctionner avec des données de format tabulaire et capables de gérer des éléments trop longs en utilisant une taille de police plus petite, en les séparant en deux lignes dans la même cellule, etc. formats plus souvent, mais la plupart des compilateurs veulent des fichiers sources exempts du type de balises que de tels éditeurs auraient besoin de stocker pour conserver la mise en forme. Utiliser des lignes avec des retraits variables mais aucune autre mise en page n'est pas aussi beau que la mise en forme tabulaire dans le meilleur des cas, mais cela ne pose pas autant de problèmes dans le pire des cas.

Il y a la déclaration 'switch' qui fournit ce genre de chose pour des cas particuliers, mais je suppose que ce n'est pas ce que vous demandez.

J'ai vu si les déclarations étaient présentées sous forme de tableau, mais il faut un grand nombre de conditions pour que cela en vaille la peine. 3 Si les déclarations sont mieux représentées dans le format traditionnel, mais si vous en avez 20, il est beaucoup plus facile de les afficher dans un gros bloc formaté pour la rendre plus claire.

Et il y a le point: la clarté. Si cela vous permet de voir plus facilement (et que votre premier exemple n’est pas facile de voir où se trouve le délimiteur), formatez-le en fonction de la situation. Sinon, restez fidèle à ce que les gens attendent, car il est toujours plus facile de le reconnaître.

Si votre expression est vraiment simple, la plupart des langages de programmation proposent l'opérateur?::

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

Ceci est un format tabulaire lisible court. Mais la partie importante est la suivante: je vois en un coup d’œil ce que l’action "majeure" est. Ceci est une déclaration de retour! Et la valeur est décidée par certaines conditions.

Si par contre vous avez des branches qui exécutent un code différent, je trouve cela beaucoup plus lisible d'indenter ces blocs. Parce que maintenant, il y a différentes actions "majeures" en fonction de l'instruction if. Dans un cas, nous lançons, dans un cas, nous enregistrons et retournons ou retournons simplement. Le déroulement du programme varie en fonction de la logique. Par conséquent, les blocs de code encapsulent les différentes branches et les rendent plus visibles pour le développeur (par exemple, lire rapidement une fonction pour saisir le déroulement du programme).

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

Comme enderland l'a déjà dit, vous supposez que vous n'avez jamais qu'un seul "retour" comme action et que vous pouvez marquer ce "retour" à la fin de la condition. Je voudrais donner quelques détails supplémentaires pour expliquer pourquoi cela ne va pas être couronné de succès.

Je ne sais pas quelles sont vos langues préférées, mais je code en C depuis longtemps. Il existe un certain nombre de normes de codage qui visent à éviter certaines erreurs de codage standard en interdisant les constructions de code sujettes aux erreurs, que ce soit lors du codage initial ou lors de la maintenance ultérieure. Je connais le mieux MISRA-C, mais il y en a d'autres, et généralement, ils appliquent des règles similaires, car ils traitent les mêmes problèmes dans la même langue.

Une erreur populaire que les normes de codage traitent souvent est cette petite erreur: -

if (x == 10)
    do_something();
    do_something_else();

Cela ne fait pas ce que vous pensez faire. En ce qui concerne C, si x est égal à 10, vous appelez do_something(), mais do_something_else()est appelé quelle que soit la valeur de x . Seule l'action qui suit immédiatement l'instruction "if" est conditionnelle. C’est peut-être ce que le codeur avait prévu, auquel cas il existe un piège pour les responsables de la maintenance; ou ce n'est peut-être pas ce que le codeur a voulu, auquel cas il y a un bug. C'est une question d'entrevue populaire.

La solution dans les normes de codage est de mandater les accolades autour de toutes les actions conditionnelles, même si elles ne concernent qu'une seule ligne. Nous avons maintenant

if (x == 10)
{
    do_something();
    do_something_else();
}

ou

if (x == 10)
{
    do_something();
}
do_something_else();

et maintenant cela fonctionne correctement et est clair pour les mainteneurs.

Vous remarquerez que cela est totalement incompatible avec votre format de style tableau.

D'autres langages (par exemple, Python) se sont penchés sur ce problème et ont décidé que, puisque les codeurs utilisaient des espaces pour clarifier la présentation, il serait judicieux d'utiliser des espaces au lieu d'accolades. Donc, en Python,

if x == 10:
    do_something()
    do_something_else()

fait les appels à la fois do_something()et do_something_else()conditionnel sur x == 10, alors que

if x == 10:
    do_something()
do_something_else()

signifie que seul do_something()est conditionnel à x et qu'il do_something_else()est toujours appelé.

C'est un concept valable, et quelques langues l'utilisent. (Je l'ai d'abord vu dans Occam2, il y a bien longtemps.) Encore une fois, vous pouvez facilement voir que votre format de style de tableau est incompatible avec le langage.

La mise en page tabulaire peut être utile dans quelques cas limités, mais il est parfois utile avec if.

Dans des cas simples: peut être un meilleur choix. Dans les cas moyens, un commutateur est souvent plus approprié (si votre langue en a un). Dans les cas complexes, vous constaterez peut-être qu’une table d’appel convient mieux.

Lors de la refactorisation du code, il m'est souvent arrivé de modifier le code afin de le rendre évident. Il est rare que je laisse les choses ainsi, car dans la plupart des cas, il existe un meilleur moyen de résoudre le problème une fois que vous le comprenez. Il est parfois interdit par une pratique de codage ou une norme de mise en page, auquel cas un commentaire est utile.

Il y avait quelques questions à propos de ?:. Oui, c’est l’opérateur ternaire (ou comme j’aime bien y penser la valeur si). à première vue, cet exemple est un peu compliqué pour?: (et abusif?: ne facilite pas la lisibilité mais le blesse), mais avec une certaine réflexion L'exemple peut être réorganisé comme ci-dessous, mais je pense que dans ce cas, un commutateur est le plus lisible Solution.

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

Je ne vois rien de mal avec le format de table. Préférence personnelle, mais j'utiliserais un ternaire comme ceci:

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

Pas besoin de répéter à returnchaque fois :)