Pourquoi PEP-8 spécifie-t-il une longueur de ligne maximale de 79 caractères? [fermé]

235

Pourquoi en ce millénaire Python PEP-8 devrait -il 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. Que faire avec l'emballage devrait être le choix du consommateur de contenu et non la responsabilité du créateur de contenu.

Y a-t-il (légitimement) de bonnes raisons d'adhérer à 79 personnages à cet âge?

python pep8

— pcorcoran
source

73

La réponse à votre question se trouve dans PEP-8.

— cdleary

29

Des longueurs de ligne plus courtes améliorent la productivité en augmentant votre KLOC. : p

— Alex

26

La limite de 79 caractères est complètement dépassée. Toute base de code modérément complexe montre comment elle rend le code beaucoup plus difficile à lire. Ex: github.com/openstack/nova/blob/master/nova/network/manager.py

— Jonathan

6

@Jonathan: ça me va bien ...

— nperson325681

9

N'utilisez-vous pas des outils de comparaison côte à côte?

— endolith

129

Une grande partie de la valeur de PEP-8 est d'empêcher les gens de se disputer sur les règles de formatage sans conséquence et de continuer à écrire du bon code au format cohérent. Bien sûr, personne ne pense vraiment que 79 est optimal, mais il n'y a aucun gain évident à le changer en 99 ou 119 ou quelle que soit votre longueur de ligne préférée. Je pense que les choix sont les suivants: suivez la règle et trouvez une cause valable à combattre, ou fournissez des données qui montrent comment la lisibilité et la productivité varient avec la longueur de la ligne. Ce dernier serait extrêmement intéressant, et aurait une bonne chance de changer les esprits des gens je pense.

28

La plupart des études de lecture se font en pouces et non en caractères par ligne. La règle des 66 caractères est basée sur des études effectuées pour lire les journaux. Des é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 en taille 12) sans perte de compréhension.

— Race

7

En fait, tous ceux qui lisent ce sujet pensent que 79 caractères est optimal. C'est pourquoi il a été ajouté au PEP8! Cette réponse est en fait fausse. Celui-ci est le bon

— erikbwork

6

Je pensais que la question était de savoir pourquoi 79 vaut mieux que 80 ou 78

— n611x007

157

there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is C'est tellement faux à bien des égards. Entourez une ligne de 40 caractères et dites-moi à quel point elle est lisible. Évidemment moins d'emballage = plus de lisibilité tant que vous avez l'espace d'écran, ce que vous avez en 2015. L'emballage a un impact sur la lisibilité. La lisibilité a un impact sur la maintenabilité. La maintenabilité a un impact sur la qualité. Et la qualité est affectée si vous enveloppez à 80 caractères. Arrêt complet.

— Jonathan

6

Discuter de la lisibilité avec tout ce qui n'est pas du code est inutile car ces études supposent l'exécution de texte. Le code semble complètement différent avec une longueur de ligne (caractère) différente à chaque ligne. Et même si vous écrivez jusqu'à la fin de la ligne, l'indentation modifie le nombre de caractères par ligne.

— Corvince

111

Garder votre code lisible par l'homme, pas seulement lisible par une machine. De nombreux appareils ne peuvent toujours afficher que 80 caractères à la fois. En outre, il permet aux personnes ayant des écrans plus grands d'effectuer plus facilement plusieurs tâches en pouvant configurer plusieurs fenêtres côte à côte.

La lisibilité est également l'une des raisons de l'indentation de ligne forcée.

— Justin Bozonier
source

58

Oui, d'accord. Mais pourquoi 79? Pourquoi pas 100 ou 120? Garder les choses lisibles fonctionne dans les deux sens. Trop de lecture ascendante et descendante du code est également difficile à gérer.

— pcorcoran

17

Il est vrai que beaucoup d'appareils ne peuvent afficher que 80 caractères. Combien d'entre eux ne peuvent pas effectuer un emballage souple?

— Jim

39

De plus, il est préférable de ne pas avoir de code. Du point de vue de l'expérience utilisateur, c'est inacceptable pour la plupart.

— Justin Bozonier le

8

Il existe certains systèmes d'exploitation comme MVS qui ne peuvent pas gérer les lignes de plus de 72 caractères. PEP-8 n'aidera pas ici. La définition d'une limite arbitraire de 79 caractères n'a aucun sens car la qualité des caractères par ligne dépend de l'éditeur, du moniteur, des préférences personnelles de l'utilisateur, etc.

— codymanix

96

79 caractères permettent également aux programmeurs d'utiliser des noms de variable et de fonction plus cryptiques et plus courts pour que tout soit adapté. C'est mauvais pour la lisibilité.

— Gert Steyn

46

Je suis un programmeur qui doit gérer quotidiennement beaucoup de code. Open source et ce qui a été développé en interne.

En tant que programmeur, je trouve utile d'ouvrir de nombreux fichiers source à la fois et d'organiser souvent mon bureau sur mon moniteur (écran large) afin que deux fichiers source soient côte à côte. Je pourrais programmer dans les deux, ou simplement lire l'un et programmer dans l'autre.

Je trouve insatisfaisant et frustrant lorsque l'un de ces fichiers source fait> 120 caractères de largeur, car cela signifie que je ne peux pas facilement ajuster une ligne de code sur une ligne d'écran. Il bouleverse le formatage pour le retour à la ligne.

Je dis «120» parce que c'est le niveau auquel je serais ennuyé que le code soit plus large que. Après autant de caractères, vous devez diviser les lignes pour plus de lisibilité, sans parler des normes de codage.

J'écris du code avec 80 colonnes en tête. C'est juste pour que quand je fuit sur cette frontière, ce n'est pas une si mauvaise chose.

— Jerub
source

11

"J'écris du code avec 80 colonnes à l'esprit. C'est juste pour que lorsque je fuit au-dessus de cette frontière, ce n'est pas une si mauvaise chose." Pareil pour moi.

— KobeJohn

4

10 ans plus tard: cela ne dépend-il pas uniquement de la façon dont vous configurez le retour à la ligne. L'habillage de ligne peut être aussi intelligent ou stupide que vous le souhaitez. Si c'est inconfortable à lire, c'est juste un échec de votre éditeur.

— David Mulder

2

Je code à 120 caractères mais parfois plus lorsque cela convient à la lisibilité. Formats noirs à 120 si vous le dites. PEP-8 dit également "qu'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 des terminaux de 80 de large. Les messages de journal ne font jamais 80 de large.

— NeilG

37

Je pense que ceux qui étudient la typographie vous diront que 66 caractères par ligne sont censés être la largeur de longueur la plus lisible. Même ainsi, si vous devez déboguer une machine à distance au cours d'une session ssh, la plupart des terminaux ont par défaut 80 caractères, 79 conviennent, 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 utilisant vim + screen comme environnement quotidien.

— Sean O Donnell
source

<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 avait des terminaux de 80x25 caractères.

— Joe D

10

Mes environnements ssh + screen + vim n'ont aucun problème à afficher les longues lignes.

— chrishiestand

54

"66 caractères par ligne sont censés être la largeur la plus lisible pour la longueur" Je suppose que nous devrions écrire du code sur 2 ou 3 colonnes, puisque c'est ainsi que les journaux sont disposés?

— Mark E. Haase

23

@mehaase: votre remarque sarcastique est assez proche de la vérité: des éditeurs décents peuvent diviser les volets et afficher différentes choses côte à côte (à partir de fichiers identiques ou différents). Par coïncidence, cela n'est généralement possible que lorsque le code a une norme de longueur de ligne ...

— nperson325681

2

@mehaase: Ça a l'air génial, en fait. Je ne plaisante pas.

— Teekin

19

L'impression d'une police à espacement fixe aux tailles par défaut est (sur papier A4) 80 colonnes par 66 lignes.

— Josh
source

11

J'accepte cette norme; c'est valide. Mais qui imprime plus de code? De plus, 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 que quelqu'un que vous connaissez a été déconcerté par leur incapacité à afficher une ligne de 100 caractères?

— pcorcoran

3

Pourquoi les gens impriment-ils du code en 2012? Cela me rappelle d'aller à une conférence sur la technologie et de recevoir un sac et un classeur imprimé plein de présentations. Ce sont les gens du 21e siècle: envoyez-moi par e-mail les diapositives ou bien ce sac et ce classeur vont directement dans une décharge.

— Mark E. Haase

2

alors pourquoi 80-1 est meilleur que 80-0 ou 80-2?

— n611x007

11

"aux tailles par défaut" vous dites? Pour en savoir plus sur ces tailles par défaut universellement acceptées.

— Bruno Bronosky

15

Oui, accordons la priorité à l'apparence de ce code sur du papier imprimé avant tout.

— Jonathan

8

Voici pourquoi j'aime les 80 caractères avec: au travail, j'utilise Vim et je travaille sur deux fichiers à la fois sur un moniteur fonctionnant à, je pense, 1680x1040 (je ne me souviens jamais). Si les lignes sont plus longues, j'ai du mal à lire les fichiers, même lorsque j'utilise le retour à la ligne. Inutile de dire que je déteste traiter avec le code des autres car ils aiment les longues lignes.

n'utilisez-vous pas également vim pour javascript / html?

— elad silver

2

@eladsilver Je ne peux pas travailler si c'est une blague? :-D

— Steven Church

désolé, pas très profond avec vim, évidemment si vous travaillez sur le web, vous l'utilisez aussi pour html / js et ces types ne sont jamais livrés avec une limite de 80 car les développeurs frontaux ne connaissent pas pep8, donc faire python limit 80-char ne résoudra pas votre problème si vous utilisez plus que python. donc ce que je demande, c'est comment gérez-vous les autres langages de codage?

— elad silver

Je travaille à Vim avec 120 lignes de caractères. J'utilise: diffthis avec split horizontal. Si vous ne pouvez ajuster que 160 caractères sur 1680 pixels, vous devez avoir une grande taille de police.

— NeilG

4

Étant donné que l'espace blanc a une signification sémantique en Python, certaines méthodes de retour à la ligne peuvent produire des résultats incorrects ou ambigus, il doit donc y avoir une limite pour éviter ces situations. Une longueur de ligne de 80 caractères est standard depuis que nous utilisons des télétypes, donc 79 caractères semblent être un choix assez sûr.

— Chris Upchurch
source

4

Il existe deux types différents d'habillage de mots. Il y a le hard-wrapping, où les lignes sont coupées avec des nouvelles lignes, et il y a le soft-wrapping, où elles ne sont affichées qu'avec des sauts, mais restent physiquement une seule ligne. Je ne vois aucun problème avec ce dernier.

— Jim

4

La plupart des éditeurs Python ne font pas de retour automatique à la ligne car il produit du code ambigu difficile à lire dans un langage où les espaces et l'indentation sont importants.

— Chris Upchurch

4

Il ne produit pas de code ambigu ou difficile à lire tant que l'emballage est visuellement identifié d'une manière ou d'une autre. Kate fait ça et ça marche bien. Si un éditeur ne gère pas cela, c'est une raison pour déposer un bogue contre l'éditeur, pas une raison pour imposer un style de codage qui évite le bogue.

— Jim

5

Même s'il est indiqué visuellement, cela rend le code beaucoup plus difficile à lire, c'est pourquoi les éditeurs Python ne le prennent généralement pas en charge.

— Chris Upchurch

L'avez-vous essayé pendant une longue période? J'ai. Cela ne rend pas le code plus difficile à lire d'après mon expérience. Pouvez-vous confirmer l'affirmation selon laquelle c'est pourquoi les éditeurs Python n'incluent pas la fonctionnalité? Je n'ai jamais entendu cette affirmation auparavant.

— Jim

1

Je suis d'accord avec Justin. Pour élaborer, les lignes de code trop longues sont plus difficiles à lire par les humains et certaines personnes peuvent avoir des largeurs de console qui ne peuvent accueillir que 80 caractères par ligne.

La recommandation de style est là pour s'assurer que le code que vous écrivez peut être lu par autant de personnes que possible sur autant de plateformes que possible et aussi confortablement que possible.

— Lecture seulement
source

10

Ceci est un argument paresseux. Il n'est pas toujours vrai que 80 lignes nuisent à la lisibilité. Un coup d'œil rapide sur n'importe quelle base de code Python modestement complexe qui encapsule 80 lignes démontre en fait le contraire - le fait d'encapsuler des appels de fonction d'une seule ligne sur plusieurs lignes rend plus difficile le suivi de WTF.

— Jonathan

0

car si vous la poussez au-delà de la 80e colonne, cela signifie que vous écrivez une ligne de code très longue et complexe qui en fait trop (et vous devez donc refactoriser), ou que vous indentez trop (et que vous devez donc refactoriser).

— Stefano Borini
source

90

-1, je ne pense pas que vous puissiez catégoriquement dire que toute ligne au-delà de la limite de 80 caractères nécessite un refactor. Les méthodes de classe sont déjà en retrait deux fois, ajoutez un autre retrait pour un "si", etc. et une compréhension de liste simple, et il est assez facile de franchir la limite de 80 caractères.

42

Sans oublier que si vous nommez des symboles de manière à ce qu'ils soient lisibles par l'homme, par exemple "users_directed_graph" au lieu de "usr_dir_gph", alors même un simple expresswion mangera pas mal de caractères par ligne.

— Mark E. Haase

8

J'ai toujours trouvé en Python que si je dépasse 80 caractères, il est sage de s'arrêter et de réfléchir à la raison. Une mauvaise décision de conception est généralement en cause.

— Mike Vella

3

C'est aussi mon expérience. Il traite également des noms de variables plus longs, comme le souligne @mehaase, mais je pense que c'est un avantage. Les combinaisons disponibles de trois mots consécutifs (dans le cas de "users_directed_graph") éclipsent le nombre de composants qui tiennent raisonnablement dans un seul espace de noms. Je considère que le code plus ancien que j'ai écrit, où de nombreux noms de variables longs similaires se trouvent dans le même espace de noms, est plus difficile à lire et généralement meilleur à refactoriser.

— TimClifford

4

Dans un langage qui nécessite des retraits pour chaque changement de portée, dire que 80 lignes de caractères équivalent à la complexité est un argument trop simpliste. Parfois, 80 caractères suffisent pour appeler une fonction. Les éditeurs / éditeurs IDE modernes pour d'autres langues sont suffisamment intelligents pour reconnaître cela et peuvent discerner quand boucler plutôt que de placer des restrictions générales sur tout ce qui nuit à la lisibilité en général.

— Jonathan