Ça dépend, si tu fais la plupart de ta prose en LaTeX par exemple, ou un autre langage de markup, ça reste utile de la considérer comme si c'était du code.
Bof, c’est pas comme du code où l’erreur peut se situer à peu près partout, là c’est juste sur quelques balises.
Surtout si tu n'es pas sûr que tu n'iras pas l'améliorer, et à plus forte raison si plus d'une personne peut éventuellement contribuer (un diff sur des lignes qui font un kilomètre c'est pas terrible, c'est plus facile d'avoir des conflits).
C’est vrai, mais c’est bien ce que je dis, l’humain qui fait le travail de la machine... Dans ce cas-là, autant faire une ligne par phrase, c’est plus logique.
Et un autre avantage à couper les lignes, c'est aussi que tu es à peu près sûr que tous les éditeurs te présenteront le texte de la même manière.
Si c’est à longueur fixe, je ne peux pas profiter de la taille de mon écran, si je réduit la taille de la vue du fichier à moins que la longueur des lignes ça va faire de la merde (problème qu’on a sur mobile quand quelqu’un écrit un commentaire et saute des lignes arrivé aux 80 caractères...). Dans ce dernier cas, le rendu n’est pas identique. D’ailleurs quel intérêt à avoir un rendu identique, le but c’est que ça puisse être lu sans emmerder le lecteur, non?
Après, en considération annexe, pour ceux qui, comme moi, utiliseraient par économie le même éditeur pour tous leurs besoins d'édition, que ce soit du code, des mails, ou tout type de prose, c'est plus simple d'utiliser les mêmes conventions partout, surtout si ledit éditeur est pensé par défaut pour des textes organisés en lignes (descendre d'une ligne perd son sens avec des lignes « paragraphe »), ce qui sera sans doute le cas s'il sert aussi à écrire du code.
Mon éditeur il fait les retours à la ligne automatique, mais si c’est à largeur fixe il sait les afficher aussi, (presque) n’importe quel éditeur sait le faire.
Je ne comprends juste pas pourquoi, à l’heure des interfaces réactives, des tailles d’écran et des fenêtres d’application à taille variable, des polices différentes, des personnes et des usages qui ne sont pas les mêmes, on doive se taper une limitation qui date des années 80.
Alors oui dans certains cas c’est pratique avec les outils que l’on a à l’heure actuelle. Mais je pense qu’on peut faire mieux.
[^] # Re: À mon tour
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Bof, c’est pas comme du code où l’erreur peut se situer à peu près partout, là c’est juste sur quelques balises.
C’est vrai, mais c’est bien ce que je dis, l’humain qui fait le travail de la machine... Dans ce cas-là, autant faire une ligne par phrase, c’est plus logique.
Si c’est à longueur fixe, je ne peux pas profiter de la taille de mon écran, si je réduit la taille de la vue du fichier à moins que la longueur des lignes ça va faire de la merde (problème qu’on a sur mobile quand quelqu’un écrit un commentaire et saute des lignes arrivé aux 80 caractères...). Dans ce dernier cas, le rendu n’est pas identique. D’ailleurs quel intérêt à avoir un rendu identique, le but c’est que ça puisse être lu sans emmerder le lecteur, non?
Mon éditeur il fait les retours à la ligne automatique, mais si c’est à largeur fixe il sait les afficher aussi, (presque) n’importe quel éditeur sait le faire.
Je ne comprends juste pas pourquoi, à l’heure des interfaces réactives, des tailles d’écran et des fenêtres d’application à taille variable, des polices différentes, des personnes et des usages qui ne sont pas les mêmes, on doive se taper une limitation qui date des années 80.
Alors oui dans certains cas c’est pratique avec les outils que l’on a à l’heure actuelle. Mais je pense qu’on peut faire mieux.
Écrit en Bépo selon l’orthographe de 1990