Tabulations ou espaces dans votre code ?

Cet article a été publié il y a 5 ans 11 mois 10 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Firefox vs Chrome, Windows vs Linux, iOS vs Android, KDE vs Gnome, systemd vs OpenRC, Node.js vs Python… Les guéguerres de clocher interminables et très souvent puériles (voire même franchement connes et toxiques) sont connues parfois même des moins techniciens tellement elles sont bruyantes. Il en est une que peu de monde entend cependant, et à laquelle je me suis confronté dernièrement. Voyons voir quel est ce problème qui concerne les développeurs à travers le monde.

Disclaimer : je ne suis pas développeur, tout juste un gros bricoleur du dimanche qui triture quelques lignes de code sur son temps libre, et également occasionnellement au boulot (ce qu’on appelle du scripting, la première étape pourrait-on dire). Si jamais je dis une énormité, il ne faut pas hésiter à me corriger mais courtoisement 🙂

De quoi on parle déjà ?

Causons un peu typographie pour commencer. Évidemment, j’ai peu de chose à dire sur l’espace, il sert d’abord à séparer les mots, et sa taille peut varier en fonction de la police de caractères ou, si on s’attaque aux possibilités de l’informatique, à l’alignement du texte par rapport à un cadre (ce texte est justifié, collez-le dans un éditeur de texte brut vous verrez qu’il n’y a qu’un espace entre chaque mot).

La tabulation, elle, remonte aux premières machines à écrire et correspond à un besoin d’aligner des éléments, à l’époque sous forme de tableaux (tabula, tableau, vous l’avez ?), plus facilement qu’avec des espaces ou des retours arrière. Lors de l’arrivée de l’informatique on en a fait un caractère spécial à part entière et la touche est restée sur nos claviers, les règles virtuelles ont remplacé les guides des machines à écrire dans les traitements de texte, et on peut définir de manière très souple la taille d’une tabulation.

La règle dans OpenOffice pour aligner le texte

Pourquoi on s’emmerde avec les deux ?

Ben après les avoir présenté je pense pas avoir besoin d’en dire beaucoup plus. L’un est juste là pour séparer des mots alors que l’autre est conçu pour de la mise en page. Mais qui n’a jamais vu quelqu’un tenter d’aligner des blocs de texte avec des espaces dans Word, avec un succès aléatoire ? Sans même parler de l’AVC que déclenche l’affichage des caractères spéciaux sur ces mêmes blocs alignés par Satan ?

On est donc face à deux outils qui dans beaucoup de cas sont soit trop peu utilisés, soit pas utilisés pour leur domaine de prédilection. Et le monde de la programmation (paie ton terme pré-millennial) ne fait pas exception, enfin presque.

C’est quoi le problème pour les développeurs ?

Le problème c’est que chaque développeur, au fur et à mesure qu’il fait des choix sur ses outils et façonne ses habitudes, sans même parler de ses langages de prédilection, peut mettre en forme son code de manière différente. Et si plusieurs devs bossent sur le même logiciel, lire un même langage avec autant de mises en forme que de personnes impliquées c’est comme lire un bouquin dont chaque page est écrite avec une police de caractère différente, sans parler du vocabulaire. Je vous laisse imaginer votre niveau de concentration sur l’histoire avec une telle présentation. Et l’une des pratiques cibles ici est l’indentation.

En fonction des langages, vous mettez un pied en enfer si les conventions d’indentation bougent au fur et à mesure que le code se déroule. C’est notamment le cas en Python, ou si vous utilisez le YAML pour vos fichiers de configuration. Mais même sans ça, la lisibilité est toute différente. Prenons un exemple tout bête en html que j’ai pu écrire y’a quelques années :

Ça c’était la version « à plat ». Et si maintenant je fais un peu d’indentation :

On comprend mieux les dépendances entre éléments, ce qui sera d’autant plus important lorsque viendront les mises en forme CSS de ces éléments. En YAML, où les éléments sont indentés avec des espaces (regardez les fichiers de ma dockerisation perso de gogs), ben le moindre espace en trop ou en moins et la stack ne démarre pas.

Comment on fait alors ?

Quand on travaille seul nos outils varient peu, et donc chacun fait comme il veut, tant qu’il reste cohérent tout au long du code source; si on suit les recommandations PEP8 de Python, ils préconisent 4 espaces pour l’indentation. Par contre quand on travaille en équipe il est nécessaire des le début d’un projet de bien définir les pratiques à suivre, de la même manière que les conventions de nommage des classes, méthodes et variables (Qui a dit CamelCase ?). L’objectif est d’éviter que le code soit difficilement lisible parce que chacun y va de sa méthode d’indentation, de taille de niveau… C’est d’autant plus vrai en Python où l’indentation est vitale pour la compréhension du code par l’interpréteur et où aucun écart n’est permis. Mixer tabulation et espace est d’ailleurs interdit en Python 3, car de par leur nature différente on ne sait pas quel niveau d’indentation appliquer à la première.

Surtout que les environnements de développement et les éditeurs de code avancés savent très bien s’accommoder et sont paramétrables sur ce plan, on peut donc forcer la taille d’une tabulation ou sa conversion directe en espaces de quantité de son choix sur son logiciel d’écriture favori.

Tu préfères quoi ?

J’ai tendance à préférer la tabulation pour plusieurs raisons. La première, c’est que c’est un seul caractère, là où vous pouvez en avoir deux, quatre ou même huit (déjà vu), et sur une base de code grossissante c’est de l’espace disque inutilement consommé selon moi. J’ai très souvent vécu dans un univers où le moindre octet compte, j’ai gardé une certaine sensibilité sur ce point; il m’arrive aussi de bosser sur des plateformes « legacy » où la taille de la partition racine est incroyablement petite et chaque octet influe sur le pourcentage d’occupation propre à déclencher des alertes préventives d’espace disque. Ceci dit si ça n’excuse pas pour autant les développeurs JavaScript qui fournissent une version « minifiée » d’un code pourtant déjà illisible (mais là aussi le moindre octet de gagné peut s’avérer payant, souvenez-vous de la conclusion de l’article sur la compression).

La deuxième c’est que de par la souplesse de l’affichage qu’on peut appliquer au caractère, plusieurs développeurs peuvent travailler sur le même code tout en appliquant la taille d’indentation qu’ils veulent sans remettre en cause la logique sous-jacente, ce qui veut dire un plus grand confort pour eux et donc plus d’efficacité. Eh oui, même les rois de l’adaptation aiment leurs petites habitudes, et en contrarier le moins possible est souvent une bonne idée.

Alors certes c’est moins pratique lorsqu’on affiche le code sans aide visuelle parce qu’une tabulation est aussi invisible que l’espace. J’ai notamment eu le tour lorsque pour mon module de mise à jour dns pour gogs, Vim sous Debian Stretch m’a ajouté des espaces dans un code Python indenté avec des tabulations sous Sublime (j’ai voulu essayer un quick fix sans tout refaire, j’ai eu des problèmes).

Ça sert à rien de pleurer alors ?

Le seul moment où vous devez pleurer c’est quand vous vous retrouvez face à un code anarchique mixant les deux sans prévenir, ce qui est courant avec les « kiddies » qui pensent qu’il suffit d’un doctorat en recherche Google/StackOverflow avec spécialisation copier-coller pour pondre un programme de mort. Non seulement ça pourrit la lisibilité, mais ça peut aussi s’avérer plantogène à fond. Sinon, pleurer revient seulement à montrer qu’on doit avoir une vie bien triste pour s’attarder sur ce qui n’est le plus souvent qu’un faux problème, surtout avec des langages qui s’en foutent royalement, comme html, php, bash (on va dire que c’est un langage hein, pour le contexte, surtout que j’écris cette conclusion un vendredi), JavaScript et j’en oublie certainement, parce que leur syntaxe les rends permissifs, et les risques de mauvaise interprétation moins nombreux.

Et vous, vous utilisez quoi pour vos indentations?