Pourquoi, dans ce millénaire, le Python devrait-il PEP-8 spécifier une longueur de ligne maximale de 79 caractères ?
Presque tous les éditeurs de code sous le soleil peuvent gérer des lignes plus longues. Ce qu'il faut faire avec l'habillage devrait être le choix du consommateur de contenu, et non la responsabilité du créateur de contenu.
Y a-t-il de bonnes raisons (légitimes) d'adhérer à 79 caractères à notre époque ?
Une grande partie de l'intérêt de PEP-8 est d'empêcher les gens de se disputer sur des règles de formatage sans importance, et de se consacrer à l'écriture d'un code bien formaté et cohérent. Bien sûr, personne ne pense vraiment que 79 est optimal, mais il n'y a pas de gain évident à le changer en 99 ou 119 ou toute autre longueur de ligne que vous préférez. Je pense que les choix sont les suivants : suivre la règle et trouver une cause valable pour laquelle se battre, ou fournir des données qui démontrent comment la lisibilité et la productivité varient avec la longueur de ligne. Cette dernière solution serait extrêmement intéressante et aurait de bonnes chances de faire changer d'avis les gens, je pense.
La plupart des études de lecture sont réalisées en pouces et non en caractères par ligne. La règle des 66 caractères est basée sur des études réalisées pour la lecture des journaux. Études récentes ont montré que lors de la lecture d'articles en ligne, la vitesse de lecture augmente jusqu'à environ 120 caractères par ligne (10 pouces avec une police de taille 12), sans perte de compréhension.
En fait, tous ceux qui ont lu ce sujet pense que 79 caractères est optimal. C'est pourquoi il a été ajouté à PEP8 ! Cette réponse est en fait fausse. Celui-ci est le bon
Faites en sorte que votre code soit lisible par l'homme et pas seulement par la machine. Beaucoup d'appareils ne peuvent encore afficher que 80 caractères à la fois. Il est également plus facile pour les personnes disposant d'un écran plus grand d'effectuer plusieurs tâches en configurant plusieurs fenêtres côte à côte.
La lisibilité est également l'une des raisons pour lesquelles l'indentation des lignes est imposée.
Oui, c'est vrai. Mais pourquoi 79 ? Pourquoi pas 100 ou 120 ? Garder les choses lisibles fonctionne dans les deux sens. Trop de lecture de haut en bas du code est également difficile à comprendre.
Il est vrai que beaucoup d'appareils ne peuvent afficher que 80 caractères. Combien d'entre eux ne peuvent pas effectuer de soft-wrapping ?
Je suis un programmeur qui a affaire à beaucoup de code au quotidien. Du code source ouvert et du code développé en interne.
En tant que programmeur, je trouve utile d'avoir plusieurs fichiers sources ouverts en même temps, et j'organise souvent mon bureau sur mon moniteur (grand écran) de façon à ce que deux fichiers sources soient côte à côte. Je peux être en train de programmer dans les deux, ou simplement en lire un et programmer dans l'autre.
Je trouve insatisfaisant et frustrant qu'un de ces fichiers source ait une largeur de >120 caractères, car cela signifie que je ne peux pas faire tenir confortablement une ligne de code sur une ligne d'écran. Le formatage est perturbé par le retour à la ligne.
Je dis "120" parce que c'est le niveau auquel je serais ennuyé par un code plus large que le mien. Au-delà de ce nombre de caractères, vous devriez séparer les lignes pour des raisons de lisibilité, sans parler des normes de codage.
J'écris le code avec 80 colonnes en tête. Ainsi, lorsque je dépasse cette limite, ce n'est pas une si mauvaise chose.
"J'écris du code avec 80 colonnes en tête. C'est juste pour que, quand je dépasse cette limite, ce ne soit pas une si mauvaise chose." Pareil pour moi.
10 ans plus tard : Cela ne dépend-il pas simplement de la façon dont on met en place le line wrapping. Le retour à la ligne peut être aussi intelligent ou stupide que vous le souhaitez. Si c'est inconfortable à lire, c'est juste une défaillance de votre éditeur.
Je code jusqu'à 120 caractères, mais parfois plus lorsque cela convient à la lisibilité. Black formate à 120 caractères si vous le lui demandez. PEP-8 dit aussi "il est acceptable d'augmenter la limite de longueur de ligne jusqu'à 99 caractères" mais les gens semblent supprimer cette information la plupart du temps. Presque personne n'utilise de terminaux d'une largeur de 80. Les messages du journal ne font jamais 80 de large.
Je crois que ceux qui étudient la typographie vous diraient que 66 caractères par ligne est censé être la largeur la plus lisible pour la longueur. Même ainsi, si vous devez déboguer une machine à distance via une session ssh, la plupart des terminaux sont réglés par défaut sur 80 caractères, 79 étant la bonne taille, essayer de travailler avec quelque chose de plus large devient une vraie douleur dans un tel cas. Vous seriez également surpris par le nombre de développeurs qui utilisent vim + screen comme environnement quotidien.
<flame>Emacs FTW!</flame> +1, cependant. Je pense que la limite de 79 vient des premiers jours d'UNIX (et peut-être de MULTICS) qui avaient des terminaux de 80x25 caractères.
"66 caractères par ligne est censé être la largeur la plus lisible pour la longueur" Je suppose que nous devrions écrire le code en 2 ou 3 colonnes, puisque c'est ainsi que les journaux sont disposés ?
J'accepte cette norme ; elle est valable. Mais qui imprime encore du code ? En outre, qui imprime du code à partir d'un environnement qui ne tolère pas la mise à l'échelle ou d'autres options de formatage ? À quand remonte la dernière fois où quelqu'un que vous connaissez a été déconcerté par son incapacité à rendre une ligne de 100 caractères ?
Pourquoi les gens impriment-ils du code en 2012 ? Cela me rappelle une conférence sur la technologie où l'on se voit remettre un sac et un classeur imprimé remplis de présentations. Nous sommes au XXIe siècle : envoyez-moi les diapositives par courrier électronique, sinon le sac et le classeur iront directement à la décharge.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
86 votes
La réponse à votre question est sur PEP-8.
38 votes
Une longueur de ligne plus courte améliore la productivité en augmentant votre KLOC. :p
13 votes
Vous n'utilisez pas des outils de comparaison côte à côte ?
2 votes
Aujourd'hui, j'ai commencé à utiliser le moniteur en portrait et ce pep est très utile pour voir le texte complet.
8 votes
Pour ceux qui remontent jusqu'aux cartes perforées, celles-ci avaient une largeur de 80 colonnes ( fr.wikipedia.org/wiki/ ). Cette valeur a ensuite été adoptée par les terminaux ASCII muets. Et s'est ensuite propagée dans d'autres "standards"...
1 votes
Un développeur python de premier plan recommande 90 ans environ youtu.be/wf-BqAjZb8M?t=260 (Formats noirs, p. 88)
1 votes
@Jonathan L'auteur du paquet Nova lié aime définitivement diviser la ligne de code sur plusieurs lignes. Il est très inconfortable pour moi de lire un tel code.
3 votes
Les formats noirs à 120 si vous lui dites de le faire. Je le fais. Le PEP-8 dit aussi "il est acceptable d'augmenter la limite de longueur de ligne jusqu'à 99 caractères" mais les gens semblent supprimer cette information la plupart du temps.
2 votes
Comment osez-vous remettre en question les mauvaises pratiques et les vices des "seniors" qui vivent encore à l'époque des tubes cathodiques ?
1 votes
@cdleary Ouaip, il a été un peu révisé au fil des ans mais il dit actuellement "Limiter la [...] largeur permet d'avoir plusieurs fichiers ouverts côte à côte, et fonctionne bien lors de l'utilisation d'outils de révision de code qui présentent les deux versions dans des colonnes adjacentes.L'enveloppement par défaut dans la plupart des outils perturbe la structure visuelle du code, ce qui le rend plus difficile à comprendre. [...] Certains outils basés sur le web peuvent ne pas offrir du tout de retour à la ligne dynamique."
0 votes
@PeterSmit Il semble être ici maintenant : github.com/openstack/nova/blob/master/nova/manager.py