Leçons à tirer du texte brut
Lorsque vous interagissez avec un fichier texte à l'aide d'un éditeur, ce que vous voyez ne reflète pas nécessairement les données stockées dans le fichier. Bien sûr, le contenu des fichiers texte brut est constitué de codes binaires codés dans des formats tels que ASCII, UTF8 ou UTF16, et ces codes binaires constituent la source ultime de vérité. Mais en fin de compte, c'est toujours votre éditeur de texte qui choisit comment interpréter et représenter cette source ultime de vérité : les codes binaires en quelque chose que vous reconnaissez. Cela signifie que deux fichiers différents peuvent se ressembler, ou que le même fichier peut apparaître différemment selon le ou les éditeurs que vous utilisez.
Votre éditeur de texte peut mettre en surbrillance (ou non) certaines parties en fonction de la syntaxe qu'il reconnaît, il peut contrôler la façon dont les tabulations apparaissent (2 espaces, 4 espaces ou même 8). Il décide comment encoder la saisie de la touche de tabulation, que ce soit sous forme d'espaces \t ou d'un nombre défini d'espaces. Il en va de même lorsque vous appuyez sur la touche Entrée pour créer une nouvelle ligne : qu'elle soit encodée sous la forme (UNIX) \n ou (Windows) \r\n dépend de la configuration de l'éditeur.
Votre éditeur de texte masque certains détails pour que vous n'ayez pas à trop réfléchir. Cependant, il arrive souvent que ces détails passent à travers la couche de protection que votre éditeur de texte tente de fournir. Et souvent, vous ne remarquez pas ces complexités avant d'y être confronté.
L'objectif principal ici est de partager certaines de mes expériences et ce que j'ai appris au fil du temps sur les problèmes courants que vous pourriez rencontrer avec du texte brut.
Tabulations et espaces
Historiquement parlant, les espaces existaient bien avant les tabulations. La raison pour laquelle les tabulations ont été initialement développées était de réduire l'utilisation répétitive de la barre d'espace et de la touche de retour arrière.
Cependant, les gens débattent encore de l'utilisation des tabulations ou des espaces dans leurs projets. Il ne s'agit pas de savoir si nous devons utiliser la touche de tabulation elle-même, mais plutôt si les éditeurs de texte doivent insérer des espaces ou des tabulations lorsque nous appuyons sur celle-ci, c'est-à-dire comment encoder les espaces vides que nous voyons dans notre éditeur lorsque nous appuyons sur la touche de tabulation.
Je pense que le principal avantage des tabulations par rapport aux espaces est la flexibilité qu'elles offrent. Lorsque vous utilisez des tabulations, vous pouvez collaborer avec de nombreuses personnes différentes qui préfèrent voir différents niveaux d'indentation, sans avoir à exposer leurs préférences par rapport aux autres. (Bien sûr, il y a aussi le fait que le caractère de tabulation prend moins de place, mais je ne pense pas que cela fasse beaucoup de différence, surtout si l'on considère que nous sommes en 2024.)
Le problème des tabulations est toutefois la précision de l'édition. Étant donné que les tabulations représentent plusieurs espaces à la fois, l'alignement des lignes peut parfois ne pas fonctionner comme prévu.
Par exemple, ce que vous voyez parfaitement comme OK dans un éditeur où les onglets sont configurés pour prendre 4 colonnes, peut être dégoûtant dans un autre éditeur où les onglets sont configurés pour prendre 2 colonnes :
Éditeur 1 avec des tabulations configurées pour occuper 4 espaces :
// 4 tabs, + 3 spaces
function calculate(a, b,
c, d) {
// Un peu de logique
}Éditeur 2 avec des tabulations configurées pour occuper 2 espaces :
// 4 tabs, + 3 spaces
function calculate(a, b,
c, d) {
// Un peu de logique
}C'est aussi en partie la raison pour laquelle j'utilise la plupart du temps des espaces. Si vous finissez toujours par ajuster la largeur des tabulations pour qu'elles correspondent aux préférences des autres, à quoi sert l'utilisation des tabulations en premier lieu ?
Je ne sais pas si cela est uniquement dû à l'avantage du premier arrivé ou non, mais il semble également que davantage de projets utilisent des espaces plutôt que des tabulations . Alors, à quoi bon aller à contre-courant alors qu'il ne semble pas y avoir un avantage très puissant de toute façon ?
Cela étant dit, je pense toujours que dans de nombreux cas, cette conversation est quelque peu excessive et ne fait souvent pas de différence pratique significative. En fin de compte, ce qui compte vraiment, c'est de savoir si la base de code est cohérente, que ce soit en utilisant des tabulations ou des espaces partout. À part cela, cela ne devrait pas avoir beaucoup d'importance puisque ces paramètres peuvent être facilement configurés dans de nombreux environnements de toute façon.
Soft Wrapping vs Hard Wrapping
Lorsque vous utilisez du texte brut, il arrive un moment où le texte que vous écrivez devient trop long. Dans de nombreux éditeurs de texte (Notepad, Notepad++, Neovim ou même VSCode), le comportement par défaut est que le texte continue de s'allonger horizontalement jusqu'à ce que vous appuyiez sur Entrée pour créer un nouveau saut de ligne. Cela peut être quelque peu peu convivial par rapport à la plupart des clients de messagerie électronique ou de messagerie, où le texte s'enroule automatiquement, ce qui le rend beaucoup plus facile à lire.
Pour être plus clair, laissez-moi vous montrer à quoi ressemblent les textes wrappé et non wrappé.
Le texte qui n'est pas wrappé :
Le texte qui est wrappé :
Comme vous pouvez le constater, le texte wrappé est beaucoup plus facile à lire que le texte non enveloppé. C'est pourquoi de nombreuses personnes ont pour habitude d'insérer des nouvelles lignes après avoir atteint un certain nombre de caractères (souvent autour de 78). En fait, dans l'éditeur de texte que j'utilise, Neovim, il suffit d'appuyer sur gq pour que cette procédure de retour à la ligne se produise pour la ligne dans laquelle vous vous trouvez.
Cette procédure qui consiste à placer des sauts de ligne réels entre le texte de façon à ce qu'il semble enveloppé est connue sous le nom de « hard-wrapping ». C'est ce que j'ai fait pendant un certain temps également, mais comme vous enveloppez une ligne en plusieurs lignes simplement parce que vous pouvez la lire plus facilement dans l'éditeur de texte, vous avez maintenant les problèmes suivants :
Il est frustrant de devoir constamment envelopper le texte manuellement, même si vous disposez d'un raccourci.
Si vous copiez le texte enveloppé de cette façon et le collez dans une autre application, comme votre application de messagerie préférée, il risque d'être désagréable à regarder, en particulier sur les appareils plus petits comme les smartphones. Cela se produit parce que lorsque la taille de l'écran est réduite, l'application de messagerie s'assure que chaque ligne est à nouveau enveloppée si elle ne correspond pas à la taille de la fenêtre verticale. Je vous recommande de lire Les problèmes liés à l'emballage dur du texte du corps des e-mails pour mieux comprendre ce phénomène.
Une fois que vous commencez à ajouter des nouvelles lignes dans votre texte juste pour le rendre plus lisible, vous sacrifiez la greppabilité. Vous pouvez considérer le terme « greppabilité » comme un moyen de décrire dans quelle mesure le texte est adapté à une recherche efficace via des outils comme grep. Dans le cas d'un texte en dur, si vous recherchez une phrase divisée sur plusieurs lignes, les outils de recherche/remplace comme grep peuvent échouer car ils fonctionnent généralement ligne par ligne.
Cette idée de greppabilité est si importante et permet de gagner du temps, en particulier lorsque vous travaillez sur une base de code. Par exemple, en général, il n'est pas très optimal de diviser votre message d'erreur ou vos messages de journal en plusieurs lignes car vous perdez la greppabilité. Voir Greppability is an underrated code metric , si vous êtes plus intéressé.
Alors, quelle est la solution ? Arrêtez le hard-wrapping et utilisez simplement le soft-wrapping , de nombreux éditeurs de texte modernes fournissent déjà des solutions de soft-wrapping. C'est ce que j'ai commencé à faire récemment. Je suis sûr qu'il existe des moyens d'y parvenir dans de nombreux éditeurs modernes. Dans Neovim, c'est aussi simple que d'utiliser les commandes suivantes :
:set linebreak
:set wrap
:set columns=80
Nouvelle ligne
Imaginons que vous collaborez avec d'autres personnes via Git et que vous venez de modifier une ligne de code dans un fichier, puis que vous l'avez transféré vers une branche. Et soudain, vos collègues ont commencé à se plaindre du fait que votre diff de validation ressemble à un changement du fichier entier.
Dans ce cas, si vous n'êtes pas sûr de ce qui se passe, vous risquez de passer un certain temps à réaliser que c'est votre éditeur de texte qui convertit automatiquement tous les caractères de saut de ligne à son format.
J'avais quelques amis qui utilisaient VSCode comme éditeur de texte principal et qui ont rencontré le même problème. Ils étaient très confus la première fois qu'ils ont rencontré ce genre de problème. Heureusement, j'étais là pour les aider à comprendre ce qui se passait. :)
Je vais faire un retour en arrière dans le temps, mais s'il vous plaît, soyez indulgents avec moi un moment.
Il y a bien longtemps, avant que les écrans ne soient monnaie courante, les gens interagissaient avec les ordinateurs à l'aide de ces appareils géniaux appelés téléscripteurs . Il s'agissait d'appareils qui combinaient un clavier pour la saisie et une imprimante pour la sortie. Vous tapiez des choses, et lorsque vous envoyiez votre commande à l'ordinateur, vous obteniez les résultats comme ceci :
Dans le contexte d'un téléprinter, ce que « nouvelle ligne » signifiait, c'était comme déplacer physiquement le chariot de la machine à écrire au début de la ligne (CR : retour chariot), puis déplacer le papier d'une ligne vers le haut (LF : saut de ligne).
Pour ces premières machines conçues pour fonctionner avec des télétypes, CR et LF étaient nécessaires pour commencer à taper sur une nouvelle ligne. Et cela a également influencé les débuts d'Unix (1971) et de MS-DOS (1981). À l'époque, les télétypes étaient encore utilisés, donc cela a dû influencer les deux systèmes d'exploitation de diverses manières. Il s'avère que les développeurs d'Unix ont choisi de simplifier le processus de création de nouvelles lignes en considérant le caractère LF seul comme signifiant la fin d'une ligne, tandis que MS-DOS a conservé la combinaison complète CR + LF. Je suppose que les gars de Microsoft étaient plus préoccupés par l'héritage et la compatibilité matérielle.
Et toutes ces conventions continuent d'exister encore aujourd'hui. Les fichiers créés sous Windows utilisent \r\n pour les nouvelles lignes et ceux générés dans les systèmes de type UNIX (Linux/MacOS/BSD) utilisent \n. Cependant, de nombreux éditeurs de texte modernes sont capables de lire et d'analyser les deux formats sur les deux systèmes d'exploitation de toute façon, de sorte que nous ne remarquons même pas ces petites différences. À moins que nous ne les gâchions avec nos git diffs :D
Pour éviter ces situations, vous pouvez configurer correctement votre éditeur de texte, utiliser un linter et créer un fichier .git/config autocrlf adapté à vos besoins.
Conclure
Même un texte brut n'est pas toujours aussi simple qu'il y paraît. Comprendre ce qui se passe en coulisses peut être utile, en particulier pour ceux qui travaillent fréquemment avec ce type de texte.
De plus, si vous avez d’autres choses à dire sur le texte brut, n’hésitez pas à les partager avec moi. J’aimerais vraiment les entendre.
Merci de m’avoir lu!