Florent Peterschmitt

La “règle” des 80 colonnes et variantes

Grand débat du jour, faut-il tout limiter à 80 colonnes pour son code et/ou sa documentation ? Et non j’ai rien d’autre à faire un vendredi soir :D

Il est répandu que 80 colonnes pour son code et même du texte, documentation dans le code ou non, c’est bien.

Dans le cas du code, c’est assez court pour éviter de devoir faire défiler le texte à l’horizontale, et de toute façon au de là d’une certaine limite « acceptable » c’est signe d’un code… bof. Pour du texte, cela évite aussi aux yeux de faire de grands sauts entre la fin d’une ligne et le début de la prochaine.

On trouve une réponse historique du côté des cartes performées IBM dont la largeur a été de 80 colonnes (mais pas seulement).

Sauf que les cartes perforées… je n’en ai jamais vu en vrai, alors pourquoi toujours 80 colonnes ?

Marche droit’d’vant toi !!

Cette règle n’est-elle pas un peu trop stricte compte tenu des outils (éditeurs) et supports (écrans) actuels ? Les écrans sont bien plus larges que 80 colonnes de texte taille 13 sur une résolution 1080p et les éditeurs disposent d’outils automatiques pour faire la mise en forme.

L’objectif actuel de limiter le nombre de colonnes dans du code source, ou du texte, est partagé par différents medias : des livres aux pages web, il est toujours désagréable de lire du texte qui n’en fini pas de s’étaler sur toute la largeur de l’écran et il semble donc parfaitement logique de limiter la taille du contenu.

En ce qui concerne le code, même tarif : lire une ligne qui n’en fini pas pose les mêmes problèmes que de lire du texte en bon françoy sur une page web, avec en plus d’horribles conséquences sur la mémorisation de ce qu’il s’y passe.

Le cas du code

if ((bla == truc && op == "bazar" && callMe(withaparam).attribute != someVal) || (urlu == (berlu + mochi) && shift >> it)) {
    patakess();
}

Dans cet exemple on est déjà à 124 colonnes, le blog vous affiche une barre de défilement horizontale, et franchement j’en ai eu marre assez vite. Même avec du code qui veut dire quelque chose, avec de vrais noms de variables explicites, de vrais noms de méthodes etc, c’est très, très chiant.

On préfèrera peut-être quelque chose du genre :

if ((bla == truc && op == "bazar" && callMe(withaparam).attribute != someVal)
    || (urlu == (berlu + mochi) && shift >> it))
{
    patakess();
}

C’est évidemment moins long, ça tient dans les 80 colonnes, on peut accéder à toutes les informations d’un coup et on a assez clairement la séparation des deux conditions ||.

Et pourtant il n’est pas toujours nécessaire d’avoir trouzillions de paramètres/conditions/whatever pour se retrouver avec des lignes aberrantes :

def je_documente_ma_fonction_avec_tous_les_types_de_parametres_dans_le_nom(prout):
    pass

J’ai réellement vu ce genre de cas. Rare, mais quand même…

Parfois même on obtient d’autres aberrations (à mon sens) quand on applique strictement la règle des 80 colonnes (ou toute autre limite) :

func DoStuff() {
    fmt.Println(
        "je suis une belle documentation, je prends soin de moi tous les jours mais " +
        "suis un peu trop longue, on va me concaténer au runtime comme un gros sac " +
        "alors que peut-être ya d’autres moyens de faire ça…"
    )
}

En soit, c’est lisible, mais ajouter des opérations dans un programme pour satisfaire une règle d’affichage pour nous pauvres humains, je trouve cela très exagéré. Et re-oui, c’est du déjà vu. Alors c’est vrai que comme c’est une donnée imutable, il est probable que le compilateur/interpréteur optimise ça… sauf que c’est toujours autant de travail manuel qui doit être réalisé.

Dans tous les cas, limiter manuellement la longueur des lignes de code semble nécessaire afin d’éviter de se perdre ou d’obtenir une indentation moche.

Le cas du texte

Pour moi, le pire du pire est de rédiger du texte (documentation) en appliquant la règle des 80 colonnes à la main.

Quand on écrit du texte, on obtient des paragraphes :

Division d'un texte de prose, d'un discours, d'un chapitre qui apparaît
typographiquement par un alinéa initial. (Dans les renvois, le paragraphe est
noté par le signe §, appelé lui-même « paragraphe ».)

Définition du Larousse

Petite section d'un discours, d'un chapitre. Ce paragraphe se lie mal au
paragraphe précédent.

Une définition du Littré

Et c’est exactement en ce sens que je comprends et utilise les paragraphes : des sections de texte un peu indépendantes des autres, des phrases qui ont un sens une fois regroupées sous un même paragraphe.

En terme de rendu visuel, un paragraphe peut être découpé sans intervention manuelle.

Par exemple, je vais vour reprendre ici la dernière phrase telles que je l’ai écrite :

Et c’est exactement en ce sens que je comprends et utilise les paragraphes : des sections de texte un peu indépendantes des autres, des phrases qui ont un sens une fois regroupées sous un même paragraphe.

Et telle qu’elle me l’est affichée dans le terminal :

Et c’est exactement en ce sens que je comprends et utilise les paragraphes : des 
sections de texte un peu indépendantes des autres, des phrases qui ont un sens une fois 
regroupées sous un même paragraphe.

La ligne fait bien plus que 80 colonnes, mais avec le retour à la ligne automatique on est à l’aise. En plus, comme je change régulièrement les mots utilisés, la mise en forme manuelle est à refaire à chaque relecture. Superbement chiant.

Retour à la ligne automatique, ou word wrap

Les éditeurs proposent tous (ne me citez pas nano… il n’est utile que quand tout le reste a merdé) de faire passer à la ligne automatiquement une ligne trop longue, avec des paramètres variables. On peut même choisir de couper en plein milieu d’un mot ou entre les mots.

On peut aussi demander au word wrap de “physiquement” couper la ligne en insérant un saut de ligne au moment où la ligne devient trop grande.

Bon, j’avais tenté ce paramétrage, au final ça devenait bien souvent complètement n’importe quoi. L’autre frein à ce mode est que lorsqu’on est pas encore fixé sur le texte/code que l’on veut écrire, on se retrouve à supprimer manuellement les sauts de ligne… bonet blanc et blanc bonet en fin de compte.

En revanche la forme « soft » du word wrap, à savoir que le retour à la ligne est une simple astuce d’affichage, me semble bien plus pratique :

  • On laisse chacun gérer sa largeur maximale.
  • On reste concentré sur ce qui est important : écrire son texte, écrire son code. La gestion manuelle des sauts de ligne n’a aucune plus-value dans du texte, et pour du code, la plupart du temps les sauts de ligne ont du sens et on s’arrête avant les 80 colonnes.

Oui, mais non

Je pense que si le word wrap ne fait pas l’unanimité, c’est peut-être que les éditeurs ne supportent pas tous le paramétrage parfait ou ont des comportements par défaut indésirables pour certains utilisateurs.

Par exemple dans Vim, pour avoir un word wrap automatique à ~100 colonnes, j’utilise tmux pour avoir un panneau à droite du texte. C’est pas super, mais en pratique j’ai trèèèèès souvent un second panneau à côté de Vim ou tout simplement un autre buffer Vim, et donc c’est devenu transparent.

Ensuite la navigation d’une ligne à une autre varie selon les utilisateurs. Je préfère qu’une “grande ligne” reste d’un seul morceau plutôt que de la fragmenter, mais ce n’est certainement pas l’avis de tout le monde.

Et puis sans doute d’autres raisons que je n’ai pas trouvé.

Keskonfé ?

Si t’es tout seul avec toi-même, on s’en fout. Le problème se pose lors de la collaboration, et je pense qu’on peut trouver des compromis :

  • Pour le texte : les documentations (README et autres), le word wrap me semble nécessaire, à l’image de ce qui se fait dans Word/LibreOffice.
  • Pour le code : on vote une limite que chacun sera tenu de respecter au mieux : si on choisis 80 est qu’on est à 85 colonnes, on va peut-être éviter de rendre le code moche juste pour respecter la règle.

Et si un compromis (celui-ci ou tout autre évidemment) ne peut être trouvé, il faut quand même que chacun utilise la même méthode : il n’y a rien de pire que d’avoir différentes conventions au sein d’un même fichier ou projet.

Comments