Discussion :

[Michael Guilloux]

Linus Torvalds : « Vos limitations matérielles ne devraient pas être un problème pour le reste d'entre nous »
le père de Linux fustige les partisans de la limite de 80 caractères par ligne de code

Si vous consultez les directives de style de code pour de nombreux langages ou projets, vous trouverez probablement une règle fixant le nombre maximal de caractères à 80 par ligne. C'est aussi souvent la configuration par défaut pour certains développeurs qui utilisent le mode console (affichant 80 caractères par ligne sur 25 lignes). Mais en 2020, cette règle est-elle encore pertinente ?

Le sujet a plusieurs fois été abordé sur des forums ou dans des listes de diffusion pour développeurs. Pour certains, cette règle est obsolète. Elle date des années 1920-1930 où les ressources matérielles étaient très limitées. Autrefois, il était nécessaire de faire tenir votre code dans 80 colonnes, sinon les caractères au-delà de la limite étaient automatiquement placés à la ligne suivante ou s'affichaient en dehors de la partie visible de l'écran, ce qui n'était pas visuellement agréable. Presque un siècle plus tard, cette règle existe encore dans le monde moderne du développement informatique.

Dans la communauté Linux, la limite des 80 caractères par ligne a souvent été au centre de discussions, comment c'était le cas le vendredi 29 mai, où un développeur a préconisé cette limite « pour toujours » dans un fil de discussions sur le nettoyage du noyau Linux. Linus Torvalds, dont la position est connue depuis plus d'une décennie, a donc profité pour dire ce qu'il pense de la limite de 80 caractères par ligne et de ceux qui s'y agrippent encore.

« Si vous ou Christoph [un développeur du noyau Linux, NDLR] avez des lignes de 80 caractères, vous obtiendrez peut-être une sortie moche. C'est pénible. Mais c'est votre choix. Vos limitations matérielles ne devraient pas être un problème pour le reste d'entre nous », lance Linus Torvalds.

Pour le père de Linux, la limite des 80 colonnes oblige à faire fréquemment des retours à la ligne. Or « les retours à la ligne excessifs sont MAUVAIS », dit-il. « Ils causent des problèmes réels et quotidiens. Ils causent des problèmes pour des choses comme "grep" à la fois dans les patterns et dans la sortie, car grep (et beaucoup d'autres utilitaires Unix très basiques) est fondamentalement basé sur les lignes. »

« Le fait est que beaucoup d'entre nous ont depuis longtemps abandonné le modèle de terminal à 80 colonnes, pour la même raison que nous avons beaucoup plus de lignes que 25 lignes visibles à la fois. Et honnêtement, je ne veux pas voir de correctifs qui aggravent l'expérience de lecture du kernel pour moi et probablement pour la grande majorité des gens, en se basant sur l'argument selon lequel certaines personnes étranges ont de petites fenêtres de terminal », ajoute Linus Torvalds.

Le créateur de Linux les invite à utiliser du matériel avec des configurations modernes. Il dit par exemple que lorsqu'il juxtapose ses fenêtres de terminal sur son écran, il peut avoir 6 terminaux visibles en même temps, et c'est parce qu'il en a trois de larges. Et, poursuit-il, « C'est avec ma fenêtre de terminal "100x50" par défaut, pas avec un 80x25 (allez dans les paramètres de votre terminal gnome, vous constaterez que le 80x25 n'est qu'une configuration par défaut que vous pouvez changer). Et la plupart de mes terminaux sont plus larges et de hauteur de plus grande que cela. J'ai vérifié, et mon principal est de 142x76 caractères en ce moment, car il s'avère que des terminaux plus larges (et de plus grande hauteur) sont utiles, et pas seulement pour le code source. »

Haussant le ton, Linus affirme qu'il y a beaucoup de choses pour lesquelles les terminaux 80x25 (80 colonnes et 25 lignes) sont vraiment limitants, et estime qu'ils ne sont plus pertinents pour la plupart des développeurs. « Donc non. Je ne me soucie pas de quelqu'un avec une fenêtre de terminal 80x25 », dit-il. Pour lui, les développeurs qui s'accrochent à une configuration de terminal 80x25 alors qu'ils ont des limitations matérielles se trouvent dans la même situation que ceux qui disent que la compilation du noyau Linux prend 10 heures alors qu'ils font le développement du noyau sur un Raspberry Pi avec 4 Go de RAM.

« Les personnes ayant un matériel restrictif ne devraient pas le rendre plus gênant pour les personnes disposant de meilleures ressources. Oui, nous accepterons les choses dans des limites raisonnables. Mais non, les terminaux à 80 colonnes en 2020 ne sont plus "raisonnables" en ce qui me concerne. Les gens utilisaient couramment des terminaux à 132 colonnes même dans les années 80, n'essayez pas de faire de 80 colonnes un standard inamovible. Si vous choisissez d'utiliser un terminal de 80 colonnes, vous pouvez vivre avec le retour à la ligne. C'est aussi simple que cela ».

De manière générale, Linus semble appeler les développeurs à tirer pleinement parti des ressources dont ils disposent aujourd'hui et d'y adapter leur style de développement. Il affirme que les lignes plus longues sont tout simplement utiles. Ce qui, selon lui, s'explique en partie par le fait que nous ne programmons plus dans les années 80, et notre code source est donc fondamentalement plus vaste. Il estime qu'être concis est toujours une bonne chose, et les noms trop verbeux ne sont pas intrinsèquement meilleurs. « Mais encore, il est tout à fait raisonnable d'avoir des noms de variables de 10 à 15 caractères et cela rend le code plus lisible », dit-il. Linus Torvalds pense aussi qu'il faut écrire des choses correctement au lieu d'utiliser des abréviations. Il justifie l'utilisation de tabulations larges par le fait que cela fait de l'indentation quelque chose qu'on peut voir dans la structure du code en un coup d'œil. « Eh oui, nous faisons des sauts de ligne à un moment donné. Mais il n'y a vraiment aucune raison de faire en sorte que ce soit après 80 colonnes », a-t-il ajouté.

Source : Linus Torvalds

Et vous ?

Que pensez-vous des déclarations de Linus Torvalds ?
La limite de 80 caractères par ligne est-elle toujours pertinente dans notre époque ? Pourquoi ?

[JPLAROCHE]

Je travaille beaucoup avec le terminal , et fait des applications pour, il est courant d'arrivé à 192x52 ou 132x40 , alors pourquoi pas 142x76, mais pour plus de lisibilité grand public 142x60 est courant.... enfin tout ça dépend des fonts, il a été souvent préconisé 15 pour les 17" ou même 18 voir 20 pour les plus 21" 13 pour les 15" là vous êtes limité a 132x40 , sur IBM 5250/3270 132x27. Le but est de rendre le plus lisible sans fatigue l'accès aux éléments, ainsi que d'être le plus simple possible.

[frfancha]

On parle de code ou de terminal ? Un peu des deux on dirait, c'est pas la même chose...
En tout cas point de vue code, mon équipe est récemment passée à visual studio code et prettier pour le front end, avec la limite à 80 caractères et prettier qui formatte automatiquement au sauvetage.
Certains étaient réticents au début...
Depuis qu'ils ont constaté l'immense avantage d'avoir des "petites" ligne lors des merges délicats ils adorent.

[Invité]

Le sujet a plusieurs fois été abordé sur des forums ou dans des listes de diffusion pour développeurs.

Oui, on peut même dire que c'est une vieille flamewar digne des tab vs espace, vi vs emacs, windows vs linux...

Elle date des années 1920-1930 où les ressources matérielles étaient très limitées. Autrefois, il était nécessaire de faire tenir votre code dans 80 colonnes, sinon les caractères au-delà de la limite étaient automatiquement placés à la ligne suivante ou s'affichaient en dehors de la partie visible de l'écran, ce qui n'était pas visuellement agréable. Presque un siècle plus tard, cette règle existe encore dans le monde moderne du développement informatique.

La contrainte matérielle n'est pas la seule raison. Il y a également la fatigue visuelle, qui augmente avec la distance latérale à parcourir. D'ailleurs certaines personnes, qui font beaucoup de texte, mettent leur écran en mode portrait.
Et puisqu'on parle des contraintes matérielles qui n'ont plus de raison d'être, pourquoi on n'alignerait pas les touches des claviers, au lieu de conserver ce décalage anti-ergonomique hérité des machines à écrire du 19e siècle?

[Lcf.vs]

Perso, j'applique toujours cette règle, pour diverses raisons :

• pour pouvoir lire des lignes entières, même dans des onglets ouverts en parallèle
• parce que c'est une convention qui est commune à plein de projets / coding styles
• car même s'il y a des projets où les conventions plus larges, je n'en connais pas à l'inverse, donc mon code suit les conventions, dans tous les cas
• car, sur des outils comme GitHub, la longueur visible des lignes est souvent limitée
• car j'ai horreur qu'il y ait un risque de devoir faire un scroll horizontal, en plus du vertical, pour lire un code
• parce que je n'ai jamais besoin de dépasser cette limite, hormis peut-être pour les regex

[Alexandre T]

Et puisqu'on parle des contraintes matérielles qui n'ont plus de raison d'être, pourquoi on n'alignerait pas les touches des claviers, au lieu de conserver ce décalage anti-ergonomique hérité des machines à écrire du 19e siècle?

Oui, dommage que les alternatives ne se démocratisent pas plus !

[le merou]

Oui, dommage que les alternatives ne se démocratisent pas plus !

Et pourquoi continuer de placer le pavé numérique à droite ? Le mettre à gauche permettrait de gagner en ergonomie. Un système modulaire c'est pas la mort à concevoir

Personnellement, j'utilise un clavier Typematrix qwerty et il possède une excellente ergonomie pour coder. Par contre c'est cher pour ce que c'est...

En ce qui concerne les 80 caractères, j'étais très réticent au début mais il s'avère que dans certains langages ça permet d'imposer une rigueur et zde réduire la complexité des méthodes en obligeant à simplifier par refactoring.

En fait le problème vient du formattage. Il faudrait que toutes les sources soient stockées en "inline" et reformatées à la volée par l'éditeur de code ou le comparateur diff en fonction de la largeur de la fenêtre. Par contre dans ce cas, catastrophe pour la mémoire visuelle qui reconnais le "schéma 2D" de la méthode.

[tome_x]

Je commence à croire que Linux c'est fait pour rester dans le passé.
Un magnifique terminal 80x25 qui émule un vt-100, 16 couleurs (ou 256 si vous avez du courage) et un éditeur modal à 2400 bauds.
Pas d'EDI, juste grep et cd.

Allez on y croit, 2021 l'année de Linux sur le desktop !

[Vulcania]

Je commence à croire que Linux c'est fait pour rester dans le passé.
Un magnifique terminal 80x25 qui émule un vt-100, 16 couleurs (ou 256 si vous avez du courage) et un éditeur modal à 2400 bauds.
Pas d'EDI, juste grep et cd.

Allez on y croit, 2021 l'année de Linux sur le desktop !

Mais ... mais ... c'est exactement l'inverse de ce qui est dit dans l'article

[technick]

Je rêve ! Il y a encore des gens pour se poser ces questions en 2020 !? Personellement je code depuis le Zx81 et je ne me suis jamais limité a quoi que soit Si le code est plus lisible sur une seule ligne, ie sera sur une seule ligne ! Et chez linux il pensent depasser le 640x480 un jour ? Suis sûr qu'ils en debattent depuis 25 ans

[foetus]

On parle de code ou de terminal ?

Il y a des éditeurs dans le terminal comme vi, ed, emacs

En ce qui concerne les 80 caractères, j'étais très réticent au début mais il s'avère que dans certains langages ça permet d'imposer une rigueur et zde réduire la complexité des méthodes en obligeant à simplifier par refactoring.

Ouais l'argument c'est de réduire le nombre d'imbrication (par exemple ne pas avoir de triple ou quadruple boucles imbriquées)

Mais justement avec l'arrivée des écrans HD (1080 ou 1200 de large), je pensais qu'on était passé à 1 limite plus grande comme 125. L'article dit "Les gens utilisaient couramment des terminaux à 132 colonnes même dans les années 80".
Donc cette limite ressemble plus à 1 fumisterie
C'est surtout lorsque tu dois manipuler ton code dans 1 écran restreint (terminal, machine virtuelle par exemple), que ton code devient illisible avec le retour à la ligne

[Zefling]

Sur le langage que j'utilise, la règle que j'ai imposé c'est une limite à 120 caractères (c'est moi qui me suis occupé du fichier de règles).
80 pour moi c'est plus chiant qu'autre chose, on passe son temps à voir comment organiser son code.
Par contre, les 120 c'est pour la lisibilité. Au delà, c'est trop long. Ça obligé à rendre son code plus lisible.
C'est juste 40 caractères de plus de 80, mais ça fait une énorme différence.

[Aizen64]

La limite des 80 caractères n’a plus vraiment de sens aujourd’hui où tout le monde à une résolution supérieure à 1280 en largeur.

Ma remarque est de ne pas fixer de limite dure tout en essayant d’éviter des lignes trop longues.

Il y a des languages où des l’inters avec une limite dure sur le nombre de caractères peut poser un vrai problème comme du markup. HTML et XML sont d’excellents exemples.

[tome_x]

Mais ... mais ... c'est exactement l'inverse de ce qui est dit dans l'article

C'est le problème qui est dit dans l'article, les gens se plaignent de ne pas pouvoir vivre comme dans les années 60. Quand ils font un grep et qu'une ligne dépasse les 80 caractères ça foire.

[lsbkf]

C'est le problème qui est dit dans l'article, les gens se plaignent de ne pas pouvoir vivre comme dans les années 60. Quand ils font un grep et qu'une ligne dépasse les 80 caractères ça foire.

Oui alors par contre si on va sur grep, on pourrait aussi vouloir afficher le nom du fichier et la ligne du match, donc la limite ce n'est plus 80 colonnes mais une valeur complètement teubée. Et puis de toutes façons en vrai, grep ça foire que dalle quand tu dépasses les colonnes de ton terminal, ou alors ces gens-là ils bossent sur une ancienne version du kernel (et des versions des outils GNU qui correspondent) que plus personne n'utilise ?? Il va falloir se mettre à jour un peu là, pour contribuer à projet c'est quand même mieux d'être pas trop loin de la dernière version.

[KiLVaiDeN]

Si on a des lignes trop longues c'est qu'on code très mal.

Ce n'est pas au développeur de faire un boulot de "compression de lignes", de réduire du code qui DEVRAIT prendre plusieurs lignes (pour des mesures de lisibilité et de débogage). Si le but d'un développeur c'est de faire des programmes en peu de lignes, c'est qu'il n'a pas compris son rôle. C'est le rôle du compilateur ou de l'interpréteur d'optimiser le code.

Le but du développeur est de résoudre le problème efficacement, en termes algorithmique, tout en ayant un code lisible. Désolé, mais une énorme ligne ce n'est pas lisible, sachant qu'en toute logique une ligne correspond à une opération.

Donc le débat de savoir "quelle est la taille max d'une ligne" est à mon avis une bêtise, l'idée étant "il faut des lignes le plus concises possibles pour améliorer la lisibilité". Si la ligne fait 180 caractères pour une raison algorithmique valide, c'est tout à fait correct mais je n'ai encore jamais rencontré de tel cas. On peut toujours décomposer.

[Sodium]

Les gens qui travaillent dans un terminal et surtout qui imposent aux autres de coder pour leurs propres limites matérielles méritent d'être pendus à un arbre.

Personnellement, je ne m'impose pas particulièrement de limites. Par contre je m'impose d'avoir un code lisible l'est rarement. Mieux vaut découper les fonctionnalités en fonction, les opérations en plusieurs étapes courtes et claires, surtout éviter les des if avec 5 possibilités qui elles-mêmes contiennent des opérations.

[Invité]

Pour un projet un peu conséquent, il est indispensable de définir un "coding style". Si chaque dev utilisait son propre formatage, bonjour l'horreur à chaque commit (sans parler que des langages comme Python utilisent l'indentation).

C'est tout à fait justifié de rediscuter le coding style d'un projet mais il faut peser tous les arguments et accepter le fait que c'est très subjectif. Ce qui est dommage ici c'est que Torvalds essaie de faire passer ses gouts personnels pour des faits objectifs. Son discours est un festival d'arguments fallacieux. Par exemple, discrétiser la limite des 80 caractères car "les dev devraient arreter d'utiliser une console des années 70 et d'imposer leurs contraintes matérielles", c'est juste un bel exemple du sophisme de l'homme de paille. Sérieux, il y a vraiment des dev du kernel qui utilisent une console des années 70 et ce serait vraiment l'unique raison de cette limite ? J'espère qu'il n'applique pas ce genre de raisonnement pour le développement du noyau...

[air-dex]

Les gens qui travaillent dans un terminal et surtout qui imposent aux autres de coder pour leurs propres limites matérielles méritent d'être pendus à un arbre.

Laisse une place pour ceux qui ne supportent pas que le JSON prenne en compte des nombres de plus de 32 bits pour la simple et bonne raison que les navigateurs sont limités à 32 bits dans les pages Web. Dans le genre limitation à justification débile celle-ci n'est pas mal non plus.

[onilink_]

Perso je me suis imposé la limite de 80 caractères, mais surtout car j'ai une police assez grosse (Source Code Pro en taille 16) et qu'au delà ça ne rentre pas bien sur mon écran (1680 pixels de large), surtout quand je commence à couper ma fenêtre de code en deux...
Comme quoi ces 80 caractères ce n'est pas si bête. Surtout si on prend aussi en compte les imbrications de code, et la lisibilité qui est toujours plus simple en colonnes qu'en lignes.

Les grosses polices ça fait bizarre au début, mais quand on à les yeux qui fatiguent ça devient quasiment une obligation.
C'est presque aussi important qu'un thème sombre et une luminosité de l'écran réduite.