Le Livre d'Argent

Cette question est, peut-être – comme la description sur mon flux RSS principal le signalait – l'un des plus vieux sujets de discorde entre les programmeurs(1). Mais sans doute faut-il d'abord commencer par quelques explications pour les non-informaticiens qui me lisent.

Une(2) espace, c'est un caractère servant, comme son nom l'indique, à insérer un espace entre les mots. Il existe en fait plusieurs sortes d'espaces, pour respecter les règles typographiques : l'espace « normale », l'espace « insécable » et l'espace « fine ». Je reviendrai, je l'espère, prochainement sur cette distinction, mais, pour l'instant, seule l'espace normale nous intéresse. C'est celle que vous ajoutez dans un texte en appuyant sur la touche rectangulaire située en bas de votre clavier, au milieu.

Quand on est en train d'afficher du texte en « langue humaine », comme par exemple ce que fait votre navigateur quand vous venez lire cet article, l'espace peut avoir une taille variable, parce qu'elle est utilisée pour les ajustement : pour que toutes les lignes semblent faire la même longueur, ce qui est plus agréable à l'œil, le logiciel va étirer, ou raccourcir, les espaces.

En revanche, pour afficher du code, ce genre de choses ne servirait à rien, au contraire, et l'on préfère plutôt utiliser un style d'affichage et une police d'écriture qui vont faire en sorte que presque tous les caractères, espaces comprises, vont apparaître de la même largeur.

Presque, parce qu'il y a une exception notable : la tabulation. Ce caractère très particulier est lui aussi un caractère blanc, c'est-à-dire qu'il n'y a rien de dessiné dans l'espace qu'il occupe, et qu'il sert à séparer les mots. Mais, à la différence de l'espace, la tabulation est prévue pour mesurer la largeur de plusieurs caractères (huit de base, mais cela peut être réglé dans la configuration du logiciel concerné).

Insérer, dans un texte, une tabulation, peut donc, visuellement, donner le même rendu que si l'on insérait plusieurs espaces (un nombre variable, en fonction des réglages et de la situation(3)). Si ça vous intéresse, ça se fait avec la touche avec les flèches située en haut à gauche du clavier, juste au dessus de la touche de verrouillage majuscule. Mais cette touche peut aussi avoir d'autres usages(4).

Le débat dont je parlais porte sur l'utilisation de l'un ou l'autre de ces caractères pour l'indentation, c'est-à-dire le décalage du début des lignes de code en fonction du bloc dans lequel elles se trouvent. Attendez, un exemple :

si il pleut
si il y a du vent
je prends mon imperméable
sinon
je prends mon parapluie

Ce code n'est pas indenté : il est nécessaire de lire le contenu et de réfléchir un peu pour essayer de comprendre quelle ligne répond à quelle autre (ça reste relativement simple sur un petit exemple comme celui-là, mais, croyez-moi, avec du vrai code, ça peut être beaucoup moins clair).

Indentons maintenant ça correctement, et voyons ce que ça donne :

si il pleut
    si il y a du vent
        je prends mon imperméable
    sinon
        je prends mon parapluie

C'est désormais beaucoup plus lisible : nous savons, au premier coup d'œil, que l'action de prendre quelque chose ne se produira que s'il pleut, et pas à un autre moment. Ensuite, l'objet choisi dépendra de la présence, ou non, de vent, l'imperméable ayant moins de risques que le parapluie de se retourner.

Cependant, une mauvaise indentation peut poser des pièges au lecteur :

si il pleut
    si il y a du vent
        je prends mon imperméable
sinon
    je prends mon parapluie

Visuellement parlant, on a désormais l'impression que le « sinon » répond au premier « si » et plus au second, ce qui n'aurait guère de sens (le parapluie ne servira pas à grand chose s'il ne pleut pas, à part peut-être comme ombrelle). C'est un cas classique de « dangling else » (on ne sait pas à quel « si » doit se raccorder le « sinon »), mais il existe d'autres sortes de codes qui posent également problème.

Dans la plupart des langages de programmation, l'indentation n'est pas prise en compte, elle sert uniquement à faciliter la lecture. Cela fait que ce que l'humain voit et ce que la machine comprend peuvent être assez radicalement différents, et ça n'aide pas à résoudre les problèmes. Cependant, certains langages, comme le Python, utilisent l'indentation pour repérer les blocs de code, et dans ce cas, une mauvaise indentation induira également la machine en erreur.

Dans tous les cas, il est donc essentiel d'indenter correctement le code.

La question est donc de savoir si l'on va utiliser, pour un niveau d'indentation donné, une tabulation, ou plusieurs espaces (généralement, quatre, mais certains préfèrent deux, ou huit. Ces trois nombres correspondent aux largeurs que l'on donne habituellement aux tabulations, la taille par défaut d'une tabulation étant généralement huit colonnes). Dans le code que je vous ai présenté ci-dessus, j'ai choisi une indentation classique de quatre espaces : le second « si » est donc au premier niveau d'indentation, c'est-à-dire décalé de quatre colonnes par rapport au début de la ligne, et l'instruction qui le suit, au deuxième niveau, est décalée de huit colonnes.

La question de savoir s'il vaut mieux utiliser des espaces ou des tabulations ne repose généralement sur aucune contrainte technique(5), mais plutôt sur le ressenti des programmeurs.

La seule chose qui soit véritablement importante est d'éviter, sauf cas très particulier, de mélanger les deux, parce que le rendu (de même que, dans les langages qui utilisent l'indentation de façon syntaxique, la réaction de la machine) peut (peuvent) devenir dans ce cas assez problématique.

Dans ce qui suit, je ne considérerai donc que les cas « uniquement des espaces » ou « uniquement des tabulations ». Les problèmes dus au fait d'insérer l'un dans un code utilisant l'autre étant symétriques d'un côté et de l'autre.

Argument le plus souvent cité, le fait qu'une tabulation ait une longueur variable, réglable en fonction du logiciel utilisé.

Pour les partisans des tabulations, c'est un avantage, car cela permet à celui qui lit de régler selon ses propres préférences (une personne utilisant des tabulations de huit colonnes de large et une personne utilisant des tabulations de quatre colonnes de large peuvent tout à fait coder ensemble, seul le rendu visuel chez l'une ou chez l'autre différera ; tandis qu'une personne utilisant quatre espaces et une en utilisant huit vont devoir se coordonner d'abord sur l'une de ces deux longueurs).

Pour les partisans des espaces, c'est un inconvénient, car le code produit n'aura pas un aspect uniforme selon le logiciel utilisé ; et parce que cela provoque donc une incertitude sur la taille des lignes (on essaye généralement de faire des lignes de code de moins de 80 colonnes de large, afin que cela puisse être lisible sur tous les écrans ; or une ligne codée avec des tabulations de 4 colonnes peut se mettre à dépasser cette taille si on l'affiche avec des tabulations de 8, par exemple).

Il y a un cas particulier, sur ce point, qui est le cas où l'on veut aligner les colonnes les unes avec les autres. Par exemple :

si il pleut
   si il y a du vent
      je prends mon imperméable
   sinon
         je prends mon parapluie

Ici, on aligne le début de l'instruction avec le début de la condition qui la détermine. Dans ce cas, les tabulations sont à éviter, puisque cet alignement ne sera plus garanti.

Je place cependant ce cas à part, dans la mesure où il ne correspond pas non plus à l'usage « habituel » des espaces : le nombre de colonnes utilisé pour indenter n'est pas un nombre fixe utilisé tel quel dans tout le programme, mais dépend de ce qu'il y a à la ligne d'avant. C'est, de mon point de vue, une troisième manière de procéder, différente des deux autres, et qui ne s'applique pas dans tous les cas.

Autre aspect à prendre en compte, la facilité d'utilisation.

Au premier coup d'œil, la tabulation peut sembler plus pratique à utiliser, dans la mesure où elle dispose d'une touche dédiée, sur laquelle un seul appui suffit (et qu'un seul appui sur une touche d'effacement permet de l'annuler), tandis qu'il faudrait plusieurs appuis sur la touche espace.

Cependant, la plupart des éditeurs peuvent être réglés de façon à ce qu'un appui sur la touche tabulation insère un certain nombre d'espaces ; et, pour les mieux conçus d'entre eux, qu'un unique appui sur une touche d'effacement supprime toutes ces espaces d'un coup.

Les partisans des espaces signalent, à juste titre, que ce réglage n'est à faire qu'une seule fois, et que, de toute façon, les programmeurs font toujours plusieurs réglages de ce genre avant de commencer à utiliser un éditeur : aucun des deux n'est donc particulièrement plus pratique que l'autre.

Les partisans des tabulations revendiquent également une certaine valeur sémantique : la tabulation est un caractère dont la fonction de base est d'obtenir de tels alignements, tandis que la fonction de base de l'espace est davantage censée être de séparer les mots. Cela fait, notamment, qu'un niveau d'indentation correspond à un seul caractère.

Cet argument est cependant rejeté par les partisans des espaces, qui considèrent que la valeur sémantique des deux caractères est à peu près la même ; et que la logique d'un caractère pour une colonne est plus importante.

Bref, les conditions sont à peu près réunies pour que les gens qui sont en désaccord le restent un certain temps. Et comme il faut bien réussir à coder ensemble, et que, comme je l'ai dit plus tôt, c'est le fait de mélanger qui provoque la plupart des problèmes, il faut trouver une autre manière de trancher.

Quand on rejoint un projet existant, c'est facile : on applique ce qui se faisait déjà. Quand on en crée un nouveau, la meilleure solution consiste à commencer par vérifier dans les recommandations du langage que vous utilisez : en général, il y a un mot ou deux là-dessus, mais ça ne conseille pas toujours explicitement l'un ou l'autre.

Statistiquement, il me semble qu'il y a plus de langages à recommander les espaces que les tabulations. Cependant, de ma modeste expérience, il me semble que la proportion de gens voulant imposer leur manière de faire est nettement plus élevé chez les partisans des espaces que chez les partisans des tabulations : il ne m'étonnerait pas que cette différence vienne en partie de là.

CC-by-nc-sa, comme précisé sur la page d'accueil

(En cas de besoin, ça ne me dérange pas d'accorder un passage sous une GNU GPL-like en cas de modifs un minimum importantes, 'suffit de demander)

Et merci

En ce qui me concerne, sur quatre espaces universitaires que j'ai fréquenté, deux laissaient faire, et deux imposaient l'usages des espaces, le premier sans tellement plus de raisons particulières autre que « pour bien coder, il faut des espaces, point », et le second, après semble-t-il un long débat entre les enseignants, parmi lesquels on compte des partisans des deux.

Mais, pour mon jugement sur le fait que la proportion de gens voulant imposer leur manière de faire me semble un peu plus grande chez les « espaceux » que chez les « tabulationnistes », je me réfère aussi au fait que la quasi-totalité des débats que j'ai croisé sur Internet sur le sujet étaient dû soit à des gens, d'un côté ou de l'autre, qui se demandaient honnêtement quel était l'avantage de l'autre pratique ; soit à des utilisateurs d'espaces qui, voyant un bout de code avec des tabulations, ont commencé à troller pour que l'autre change ça. Il existe, très probablement, des utilisateurs des tabulations faisant de même ; simplement, de ma modeste expérience, je ne me souviens pas en avoir déjà croisé.