Pourquoi ne PEP-8 spécifier une longueur de câble maximale de 79 caractères?

Pourquoi dans ce millénaire Python PEP-8 spécifier une longueur de câble maximale de 79 caractères?

À peu près chaque éditeur de code sous le soleil peut gérer les lignes les plus longues. Que faire avec du papier d'emballage doit être le choix du contenu à la consommation, la responsabilité de l'auteur du contenu.

Y (légitimement) de bonnes raisons pour adhérer à 79 caractères à cet âge?

  • La réponse à votre question est dans la PEP-8.
  • De plus courtes longueurs d'améliorer la productivité en augmentant votre KLOC. :p
  • 79 limite de caractères est complètement dépassée. Tout modestement complexe de la base de code montre comment il rend le code plus difficile à lire. Ex: github.com/openstack/nova/blob/master/nova/network/manager.py
  • semble bien pour moi...
  • N'avez-vous pas des gens utilisent à côté de diff outils?
  • Aujourd'hui, j'ai commencé à utiliser le moniteur en mode portrait et ce pep est très utile pour voir en plein texte.
  • Pour ceux qui aller aussi loin que les cartes perforées, les cartes perforées ont été de 80 colonnes en largeur (en.wikipedia.org/wiki/...). Cette valeur a ensuite été adopté par muette les terminaux ASCII. Et puis s'est propagée dans d'autres "normes"...
  • Leader python core developer recommande 90ish youtu.être/wf-BqAjZb8M?t=260 (Noir formats (88)
  • L'auteur de la Nouvelle package certainement aime le fractionnement de la ligne de code sur plusieurs lignes. Il est très désagréable de lire un tel code pour moi.
  • Noir formats de 120 si vous dites qu'il. Je ne. PEP-8 dit aussi: "c'est d'accord pour augmenter la longueur de la ligne de limite jusqu'à 99 caractères" mais les gens semblent pour supprimer cette information beaucoup de temps.

InformationsquelleAutor pcorcoran | 2008-09-18
  1. 104

    Grande partie de la valeur de la PEP-8 est d'empêcher les gens de se disputer sur le sans conséquence règles de mise en forme, et de bien écrire, régulièrement mises en forme du code. Bien sûr, personne ne croit vraiment que la 79 est optimale, mais il n'y a pas de gain évident de le changer à 99 ou 119 ou quel que soit votre choix de la longueur de la ligne est. Je pense que les choix sont les suivants: suivre la règle et de trouver une cause valable de bataille, ou de fournir des données qui montre comment la lisibilité et de la productivité varient avec la longueur de la ligne. Ce dernier serait extrêmement intéressant, et aurait une bonne chance de changer l'esprit des gens je pense.

    • Plus lire les études sont faites en pouces et pas de caractères par ligne. 66 personnage règle est fondée sur des études menées pour la lecture des 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 à la taille de police 12) sans perte de compréhension.
    • En fait tout le monde qui a lu dans ce sujet pense 79 caractères est optimal. C'est pourquoi il a été ajouté à PEP8! Cette réponse est en fait mal. celui-ci est le bon
    • Je pensais que la question est à propos, pourquoi 79 est mieux que 80 78
    • Le plus gros problème que j'ai avec ce que j'ai, comme presque tous les programmeurs que je sais, utiliser le même terminal pour l'édition de code et l'exécution de code. Si vous configurez votre terminal 80ish large de sorte que vous avez de la place pour d'autres choses sur votre écran, lorsque vous exécutez votre code, votre stacktraces et les fichiers journaux sont illisibles. Cela vous forcera à utiliser un plus grand terminal. Par conséquent, votre éditeur de texte est perdre de l'espace. Pourquoi ne pas utiliser les bornes séparées? Parfois nous faisons, mais pour 95% des cas, 1 fenêtre de terminal avec 1 tmux à l'intérieur optimal "de mon chemin et laissez-moi le code".
    • 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. Envelopper d'une ligne de 40 caractères et dites-moi comment lisible, il est. Évidemment moins d'emballage = plus de lisibilité aussi longtemps que vous avez l'espace de l'écran, qui en 2015, vous ne. Emballage impacts des raisons de lisibilité. La lisibilité de l'impact de la maintenabilité. La maintenabilité des répercussions sur la qualité. Et la qualité est affectée si vous êtes d'emballage à 80 caractères. L'arrêt complet.
    • Les "Récentes études" lien est rompu. Pouvez-vous fournir une version actualisée?
    • Si vous recherchez "la longueur de la ligne" dans le lien donné, vous obtiendrez une liste de résultats. Le premier que j'ai eu était un article intitulé de la Lecture à l'Écran: Les Effets de la Longueur de la Ligne sur la Performance qui dit 95 caractères par ligne a été le meilleur dans une étude de 2005 (qui a été la plus longue qu'ils ont été testés). La facilité d'utilisation de l'étude elle-même est disponible ici. Notamment, les participants à l'étude n'est pas lire le code de l'ordinateur.
    • Faisant valoir à propos de la lisibilité avec quelque chose de non-code est inutile que ces études supposent l'exécution de texte. Code semble complètement différentes avec d'autres (caractère) longueur de chaque ligne. Et même si vous écrivez jusqu'à la fin de la ligne, l'indentation des changements de la quantité de caractères par ligne.
    • Aussi mon vt52 borne n'est que de 80 caractères.
    • PEP-8 dit aussi: "c'est d'accord pour augmenter la longueur de la ligne de limite jusqu'à 99 caractères" mais les gens semblent pour supprimer cette information beaucoup de temps.

    InformationsquelleAutor
  2. 102

    En gardant votre code lisible par un humain et pas seulement lisible par la machine. Beaucoup de dispositifs ne peut montrer de 80 caractères à la fois. Il fait également plus facile pour les gens avec de plus grands écrans multi-tâche en étant capable de mettre en place plusieurs fenêtres côte à côte.

    La lisibilité est aussi l'une des raisons pour forcées en ligne de l'indentation.

    • Oui, accordée. Mais pourquoi 79? Pourquoi pas 100 ou 120? Garder les choses lisibles dans les deux sens. Trop haut et en bas de la lecture de code est difficile à analyser trop.
    • Il est vrai que beaucoup d'appareils ne peuvent montrer de 80 caractères. Combien d'entre eux ne peuvent pas effectuer un soft-emballage?
    • La plupart Python spécifique éditeurs ne fais pas de mot doux de l'emballage.
    • Aussi, il est préférable de ne pas avoir de code de les emballer. À partir d'une perspective de l'expérience utilisateur, il est inacceptable pour la plupart.
    • Il y a certains systèmes d'exploitation comme MVS qui ne peut pas gérer les lignes de plus de 72 caractères. PEP-8 ne sera pas vous aider ici. Réglage d'une limite arbitraire de 79 caractères n'a pas de sens depuis combien de caractères par ligne sont de bonnes dépend de l'éditeur, le moniteur, les préférences personnelles de l'utilisateur et ainsi de suite.
    • ce qui devrait avoir été marqué répondre
    • 79 vient de l'époque des imprimantes matricielles, ils ne imprimée 80 caractères par ligne. Aujourd'hui, nous sommes tous assis avec un ratio 16:9 affiche avec beaucoup de largeur et limitée de l'espace vertical... j'ai suivi toutes les règles de PEP8 sauf celui-ci, je crois qu'il devrait être mis en conformité avec la technologie actuelle.
    • 79 caractères rend également les programmeurs utilisent plus courte, plus énigmatiques, les variables et les noms de fonction pour tout faire rentrer. C'est mauvais pour la lisibilité.
    • pourquoi est-80-1 mieux que 80-0 ou 80-2?
    • nous sommes tous assis ne sous-estimez pas le codage via ssh à côté d'un stand avec pas de chaises sur un oldschool 4:3.
    • Il est intéressant de noter que cette réponse est obsolète en 2015, où même mon téléphone portable a une résolution suffisante pour lire une ligne de code avec > 80 caractères.
    • J'ai mis en place avec une verticale de surveiller avec une grande police (si je peux m'asseoir plus loin de l'écran) et souvent diviser mon éditeur de windows afin que je puisse travailler sur plusieurs fichiers à la fois. La longueur de la ligne de restrictions vraiment améliorer mon lisibilité.
    • Readability is also one of the reasons for enforced line indentation D'accord, mais forcé de la ligne d'emballage rend le code moins lisible.

    InformationsquelleAutor Justin Bozonier
  3. 39

    Je suis un programmeur qui doit faire face à beaucoup de code sur une base quotidienne. L'Open source et de ce qui a été développé en interne.

    En tant que programmeur, je trouve qu'il est utile d'avoir plusieurs fichiers source ouverte à la fois, et souvent organiser des mon bureau sur mon (grand écran) moniteur de manière à ce que les deux fichiers source sont côte à côte. J'ai peut-être la programmation dans les deux, ou tout simplement la lecture de l'une et de programmation dans l'autre.

    Je trouve insatisfaisante et frustrant lorsque l'un de ces fichiers source >120 caractères en largeur, car il ne me permet pas de s'adapter confortablement à une ligne de code sur une ligne de l'écran. Il dérange mise en forme de ligne à ligne.

    Je dis '120' parce que c'est le niveau sur lequel je voudrais m'irrite au code étant plus large que. Après que le nombre de caractères, vous devez être le fractionnement sur plusieurs lignes pour des raisons de lisibilité, sans parler des normes de codage.

    Je écrire du code avec 80 colonnes à l'esprit. C'est juste pour que quand je ne coulent plus que limite, c'est pas une mauvaise chose.

    • "J'écris du code 80 colonnes à l'esprit. C'est juste pour que quand je ne coulent plus que limite, c'est pas une mauvaise chose." De même pour moi.
    • 10 ans plus tard: Ne pas seulement dépendre de la façon dont vous définissez retour à la ligne. Retour à la ligne peut être aussi intelligent ou stupide que vous le souhaitez. Si il est mal à l'aise de lire que c'est juste une panne de votre éditeur.
    • Je code à 120 caractères, mais parfois plus quand il convient de lisibilité. Noir formats de 120 si vous dites qu'il. PEP-8 dit aussi: "c'est d'accord pour augmenter la longueur de la ligne de limite jusqu'à 99 caractères" mais les gens semblent pour supprimer cette information beaucoup de temps. Presque personne n'utilise les terminaux qui sont 80 de large. Journal des messages ne sont jamais 80 de large.
    InformationsquelleAutor Jerub
  4. 36

    Je crois que ceux qui ont étudié la typographie vous dire que 66 caractères par ligne est censé être le plus lisible largeur de la longueur. De même, si vous avez besoin de déboguer une machine à distance via une session ssh, la plupart des terminaux par défaut à 80 caractères, 79 rentre tout juste, en essayant de travailler avec quelque chose de plus large devient une vraie douleur dans un tel cas. Vous pourriez également être surpris par le nombre de développeurs à l'aide de vim + écran comme un jour de la journée de l'environnement.

    • <la flamme>Emacs FTW!</flamme> +1, si. Je pense que l'79 limite vient dès les premiers jours de UNIX (et éventuellement MULTICS), qui n'a de caractère 80x25 terminaux.
    • Mon ssh+écran+vim environemnts ont pas de problème d'affichage de longues lignes.
    • "66 caractères par ligne est censé être le plus lisible largeur de longueur" je suppose que nous devrions écrire du code en 2 ou 3 colonnes, puisque c'est la façon dont les journaux sont prévues?
    • votre remarque sarcastique, est assez proche de la vérité: décent, les éditeurs peuvent faire split volets et de montrer des choses différentes side-by-side (de la même ou dans des fichiers différents). Par coïncidence, ce n'est généralement possible que lorsque le code a une longueur de ligne standard...
    • Ça a l'air génial, en fait. Je ne plaisante pas.
    InformationsquelleAutor Sean O Donnell
  5. 19

    L'impression d'une police à chasse fixe, à des tailles par défaut est (sur papier A4) 80 colonnes par les lignes 66.

    • J'accepte la présente norme; il est valide. Mais qui imprime le code plus? En outre, qui imprime le code d'un environnement qui est intolérant de la mise à l'échelle ou d'autres options de mise en forme? Quand était la dernière fois que quelqu'un que vous connaissez a été déconcerté par leur incapacité à rendre une ligne de 100 caractères?
    • Pourquoi les gens d'impression de code en 2012? Cela me rappelle d'aller à une conférence sur la technologie, et d'être remis un sac et un imprimé classeur plein de présentations. C'est le 21e siècle, les gens: e-mail me les diapositives ou autre sac et le liant sont d'aller directement dans un site d'enfouissement.
    • alors pourquoi 80-1 est mieux que 80-0 ou 80-2?
    • "à défaut tailles" dites-Vous? M'en dire plus sur ces universellement acceptée des tailles par défaut.
    • Oui, nous allons prioriser la façon dont le code ressemble à une impression sur papier au-dessus de tout le reste.
    InformationsquelleAutor Josh
  6. 7

    Voici pourquoi j'aime les années 80 caractères avec: au travail, j'utilise Vim et de travailler sur les deux fichiers à la fois sur un moniteur fonctionne à, je pense, 1680x1040 (je ne me souviens jamais). Si les lignes ne sont plus du tout, j'ai de la difficulté à lire les fichiers, même lors de l'utilisation de word wrap. Inutile de dire que je déteste les relations avec les gens du code qu'ils aiment les longues lignes.

    • ne pas utiliser vim pour javascript/html ainsi?
    • Je ne peux pas savoir si c'est une blague? 😀
    • désolé, pas très profonde avec vim, évidemment, si vous travaillez dans le web, vous utilisez également pour le html/js et ces types ne s'accompagnent jamais de 80 caractères limite depuis développeurs front end ne sais pas à propos de pep8, afin de faire de python limite de 80 caractères ne résolvent pas votre problème si vous utilisez plus alors seulement de python. donc, ce que je demande est de savoir comment vous gérer d'autres langages de programmation?
    • Je travaille dans Vim avec 120 lignes de caractères. J'utilise :diffthis avec split horizontal. Si vous ne peut correspondre à 160 caractères sur 1680 pixels, vous devez avoir une grande taille de police.
    InformationsquelleAutor
  7. 3

    Depuis les espaces a de sens sémantique en Python, certaines méthodes d'habillage du mot pourrait produire incorrectes ou des résultats ambigus, donc il doit être une limite pour éviter ces situations. Un de 80 caractères la longueur de la ligne a été la norme depuis que nous avons été à l'aide de modèles, afin de 79 caractères semble être une très sécuritaire choix.

    • Il y a deux différents types de mot-emballage. Il est difficile d'habillage, où les lignes sont séparées par des retours à la ligne, et il est doux d'habillage, où ils ne sont que affiche avec des pauses, mais restent physiquement une seule ligne. Je ne vois pas de problème avec cette dernière.
    • La plupart Python éditeurs ne fais pas de mot doux d'emballage, car elle produit ambigu dur à lire le code dans un langage où les espaces et l'indentation est important.
    • Il ne produit pas d'ambigu ou difficiles à lire le code, tant que l'emballage est identifié visuellement en quelque sorte. Kate fait cela, et il fonctionne très bien. Si un éditeur ne gère pas cela, alors c'est une raison de soumettre un rapport de bogue à l'encontre de l'éditeur, n'est pas une raison pour imposer un style de codage qui permet d'éviter le bug.
    • Même si c'est indiqué visuellement, il est toujours en rend le code plus difficile à lire, c'est pourquoi Python éditeurs n'ont généralement pas le soutenir.
    • Avez-vous réellement essayé pendant une longue période de temps? J'ai. Il ne veut pas rendre le code plus difficile à lire dans mon expérience. Vous pouvez sauvegarder la demande qui c'est pourquoi Python éditeurs ne comprennent pas la fonction? Je n'ai jamais entendu qui prétendent avant.
    InformationsquelleAutor Chris Upchurch
  8. 1

    Je suis d'accord avec Justin. D'élaborer, de trop longues lignes de code sont plus difficiles à lire par les humains et certaines personnes pourraient avoir de la console largeurs seulement d'accueillir jusqu'à 80 caractères par ligne.

    Le style recommandation est là pour s'assurer que le code que vous écrivez peut être lu par le plus grand nombre possible de personnes sur autant de plates-formes que possible et aussi confortablement que possible.

    • C'est un argument paresseux. Il n'est pas toujours le cas que les 80 lignes de nuit à la lisibilité. Un rapide coup d'œil à tout modestement complexe Python code qui encapsule à 80 lignes en réalité démontre le contraire - que l'emballage seule ligne des appels de fonction à plusieurs lignes, il est plus difficile de suivre WTF qui se passe.
    InformationsquelleAutor Readonly
  9. 1

    parce que si vous le poussez au-delà de la 80e colonne, cela signifie que vous avez écrit un très long et complexe et de la ligne de code qui en fait trop (et donc vous devriez refactor), ou que vous en retrait trop (et donc vous devriez refactor).

    • -1, je ne pense pas que vous pouvez catégoriquement dire que toute la ligne après la 80 char limite nécessite un peu de remaniement. Les méthodes de la classe sont déjà en retrait par deux fois, ajouter un autre tiret pour un "si", etc. et une simple compréhension de liste, et il est assez facile de traverser les années 80-char de la frontière.
    • Pour ne pas mentionner 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 va manger tout à fait un peu de caractères par ligne.
    • J'ai toujours trouvé en Python que si je dépasse 80 caractères de son sage de s'arrêter et de réfléchir à la raison qui est. En général mauvaise décision de conception est en faute.
    • Cela a été mon expérience en tant que bien. Il traite également de plus les noms de variables, comme @mehaase points, mais je pense que c'est un avantage. Les combinaisons de trois mots consécutifs (dans le cas de "users_directed_graph") réduisent le nombre de composants que raisonnablement s'inscrire dans un seul espace de noms. Je considère que âgées de code que j'ai écrit où beaucoup de semblables longtemps les noms de variables sont dans le même espace de noms à être plus difficiles à lire, et généralement mieux à refactoriser.
    • Dans une langue qui nécessite des tirets pour chaque modification de la portée, en disant que 80 lignes de caractères correspond à la complexité est un peu trop simpliste argument. Parfois 80 caractères est juste ce qu'il faut pour appeler une fonction. Moderne IDE/éditeurs pour les autres langues sont assez intelligents pour reconnaître ce fait et peut discerner lors de l'envelopper plutôt que de placer des restrictions générales sur tout ce qui nuit à la lisibilité de l'ensemble.
    • C'est gravement erronée. C'est une bonne raison de faire une pause lorsque le code dépasse 79 personnages, mais ça ne veut pas nécessairement dire qu'il est trop long et trop complexe ni n'exige la refactorisation.
    • Si je me souviens bien, l'original de la raison derrière le 79 caractères a été due, en partie, par les vieux ordinateurs de l'école / invite de commande / de la ligne de commande n'ayant qu'une seule 79 caractères de longueur. Le moment que vous êtes allé au-delà du nombre de caractères, vous avez formé une nouvelle ligne et donc illisible. Ce n'est pas le cas aujourd'hui, il semble tout à fait agréable.

    InformationsquelleAutor Stefano Borini