Les développeurs de logiciels ne manqueront jamais de sujets pour discuter et se battre. Certains d'entre eux peuvent être fondamentaux pour un choix de langage comme un projet ou le paradigme de programmation pour commencer. D'autres semblent plus une préférence personnelle au premier abord, mais peuvent se révéler tout aussi fondamentaux à plus grande échelle – comme le caractère à choisir pour l'indentation, où placer les accolades ou comment gérer les sauts de ligne. Plus tard, lorsque plusieurs développeurs collaborent, il est temps de trouver un accord commun sous la forme d'un guide de style de codage, ce qui pourrait bien sûr nécessiter un peu de compromis.

Indépendamment du goût, la pire décision est de ne pas avoir de décision, et même si vous n'êtes pas d'accord avec un détail spécifique, il est généralement préférable de faire la paix avec elle au profit d'un code au format uniforme. Dans un environnement professionnel, un guide de style a été idéalement élaboré en collaboration au sein ou entre les équipes, et les commentaires et opinions de toutes les personnes impliquées ont été pris en considération – et si votre entreprise n'en a pas pour commencer, la meilleure étape à suivre est probablement un vers la sortie.

La situation peut devenir un peu plus complexe dans les projets open source, selon la structure et la taille d'un projet. S'il n'existe pas de guide de style officiel, la chose gracieuse à faire est simplement d'adopter le style actuel de la base de code lorsque vous y contribuez. Mais les grands projets qui sont habitués à une multitude de contributeurs aléatoires en auront généralement un défini, qui a été élaboré par les développeurs principaux ou déclaré par son dictateur bienveillant à vie.

Dans le cas du noyau Linux, c'est bien sûr (Linus Torvalds), qui a récemment secoué la communauté avec une réponse de liste de diffusion déclarant une règle de formatage de code trop courante, souvent même non écrite, comme essentiellement obsolète: la limitation de 80 caractères. Compte tenu de la notoriété de ses diatribes et de sa grossièreté, sa réponse, qui a été déclenchée par un changement de ligne dans le patch soumis, semble carrément diplomatique cette fois.

Le raisonnement de (Linus) contre une application continue des limites de ligne de 80 caractères est principalement le fait que les écrans sont tout simplement assez grands aujourd'hui pour s'adapter confortablement à des lignes plus longues, même avec plusieurs terminaux (ou fenêtres) côte à côte. Comme il le dit, la seule raison de s'en tenir à la limitation est d'utiliser un VT100 réel, qui ne servira de toute façon pas beaucoup au développement du noyau.

L'autorisation de lignes plus longues, d'autre part, encouragerait l'utilisation de noms de variables et d'espaces plus verbeux, ce qui augmenterait en fait la lisibilité. Bien sûr, tout dans une certaine mesure, et (Linus) n'appelle évidemment pas complètement à la suppression des sauts de ligne. Mais il a raison; est-il vraiment logique de s'en tenir à une limitation vieille de plusieurs décennies, de nos jours plutôt arbitraire, en 2020?

Longueurs de ligne tout au long de l'historique

D'où vient cette limitation de toute façon? Cela semble être une de ces choses que tout le monde connaît et suit sans remettre en question ni vraiment le comprendre. Les 80 caractères sont tout autour de nous – il y a ces appareils d'antan avec leurs affichages de 80 caractères, la largeur par défaut de votre émulateur de terminal est prédéfinie à 80 colonnes, et bien sûr tous ces guides de style de codage qui augmentent la limite de 80 caractères. Tout semble magiquement se réunir d'une manière ou d'une autre, et c'est ainsi que les choses se passent, point final. Eh bien, cela n'a pas aidé du tout maintenant, n'est-ce pas? Revenons donc en arrière.

Tout a commencé ici.

Oui, depuis les débuts des terminaux, la taille de l'écran était en effet principalement limitée à 80 caractères. Il y avait des exceptions dans les deux sens, 72 et 132 par exemple, mais 80 était la plus courante. Considérant que nous parlons de la fin des années 1960 ici, il semble plausible que la technologie d'affichage n'était tout simplement pas assez avancée pour permettre d'avoir des écrans plus grands et des lignes plus longues, et c'est ainsi qu'ils se sont retrouvés avec 80 caractères. Mais ce n'est pas ça non plus.

Bien sûr, l'état de la technologie d'affichage des années 1960 a certainement eu un certain impact, mais le choix a finalement été fait par habitude plutôt que par nécessité. À l'époque, lorsque les premiers terminaux ont été conçus, les personnes travaillant avec n'importe quel ordinateur ressemblaient principalement à un support de stockage commun: les cartes perforées. La star du moment, dominant l'industrie, était la carte de 80 colonnes par 12 lignes d'IBM. Et bien, c'est à peu près tout.

La popularité de cette carte spécifique a conduit à la décision d'utiliser la même quantité de colonnes sur les terminaux, ce qui à son tour l'a définie comme la norme d'or pour les styles de codage, encore largement utilisée aujourd'hui. D'une certaine façon, c'est compréhensible, étant donné que la carte perforée 80 × 12 était littéralement la plus grande invention depuis le pain tranché à l'époque – comme les deux ont été révélés au monde en juillet 1928. Oui, l'origine complète de 80 caractères remonte essentiellement à 1928 .

(La demande de brevet de la carte a été déposée le 20 juillet 1928, le premier pain tranché a été vendu le 7 juillet 1928)

Longueurs de ligne actuelles

Nous voici donc, près d'un siècle plus tard, toujours en train de serrer le texte dans les mêmes 80 lignes de caractères. Eh bien, pas partout, certaines langues le voient différemment aujourd'hui, et sinon, les frameworks pourraient avoir leurs propres directives. Mais alors que nous avons de plus grands écrans à notre disposition de nos jours, les longues lignes finiront par interférer avec notre champ de vision. En d'autres termes, nous oblige à bouger nos yeux, voire la tête entière, perturbant le flux de lecture et augmentant le risque d'oublier quelque chose d'important.

Là encore, la discussion ne vise pas à se débarrasser complètement des limites de ligne, mais à contester une limite stricte et forcée de 80 caractères. Du point de vue du confort de lecture, la différence entre 80 et 85 par exemple est négligeable, et insister sur le premier conduira au mieux à des sauts de ligne maladroits – comme celui adressé (Linus) – et au pire aux noms de variables cryptiques et autres formatage discutable.

Un compromis courant consiste à encourager 80 caractères, mais autorisez jusqu'à 100 ou 120 caractères, et tracez la limite stricte à cet endroit. De cette façon, si vous dépassez la limite douce, vous n'avez pas à transpirer trop, et au moment où vous atteignez la limite dure, il y a assez de place pour diviser les lignes de manière cohérente.

Dans un monde idéal, rien de tout cela n'aurait beaucoup d'importance et un IDE gérerait tout cela de manière transparente pour nous. Nous configurerions la limite du guide de style et définirions également notre propre limite préférée. L'IDE présente le code tel que nous le préférons et l'enregistre comme le guide de style le demande.

Bien que cela fonctionne assez bien avec des choses comme le style d'indentation, les sauts de ligne sont malheureusement beaucoup plus complexes. Où est le bon endroit pour diviser pour garder le code lisible et préserver les blocs logiques? Si cela est fait naïvement en forçant brutalement les sauts de ligne, nous sommes exactement de retour au point (Linus Torvalds) essaie de faire. Peut-être que l'apprentissage automatique nous y mènera à l'avenir, mais d'ici là, nous sommes seuls.

C'est quoi Votre Limite?

Alors, que pensez-vous de tout cela? Où avez-vous défini votre limite de longueur de ligne? Et vos projets parallèles diffèrent-ils de votre environnement de travail ici?

Êtes-vous d'accord avec (Linus) et dites déjà assez avec la folie forcée de 80 caractères? Ou préférez-vous des lignes encore plus courtes?

Faites le nous savoir dans les commentaires!

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici