Des études sur la largeur de code optimale?

131

Si vous activez "Afficher la marge de droite" dans votre IDE de choix, il est probable qu'il soit par défaut à 80 caractères. J'ai tendance à le changer à 120 sans autre raison que c'était la norme dans une entreprise que j'étais il y a quelques années, et aucune autre entreprise ne m'a dit de le faire différemment.

Ma question est la suivante: y a-t-il des études qui montrent que 80 caractères sont la largeur maximale optimale pour la lisibilité du code, ou est-ce que cette valeur est juste un «c'est comme ça que ça a toujours été» et personne ne sait vraiment pourquoi c'est ainsi? Et la largeur d'une ligne de code devrait-elle faire partie de votre norme de codage?

code-readability

— Fostah
source

1

Bien que je ne connaisse aucune étude, vous trouverez de nombreuses opinions pour répondre à cette question: * Y a-t-il une raison valable pour appliquer une largeur maximale de 80 caractères dans un fichier de code, à ce jour?

— Adam Bellaire

3

aucune étude à ma connaissance, mais vous trouverez peut-être intéressant d'examiner les normes de codage de différents projets. Par exemple, Google contient 80 caractères. ( code.google.com/p/google-styleguide ) où comme WebKit (ala Apple?) n'ont pas de limite AFAIK ( webkit.org/coding/coding-style.html ). Mozilla semble avoir 80 ans ( developer.mozilla.org/En/Mozilla_Coding_Style_Guide#Line_length )

— gman

C'est la même chose que la raison pour laquelle nous épelons «Bureaucrate» comme nous le faisons. Parce qu'il y a longtemps, quelqu'un a défini une norme pour une raison qui pouvait ou non avoir du sens à l'époque. Pour l'orthographe, c'était une fascination douteuse pour le latin, pour le code de la taille d'une carte perforée en papier. Ensuite, une méthode a été étiquetée «correcte». Et les petits bureaucrates appliquent les normes depuis lors.

— Tuntable

116

En fait, la chose de 80 colonnes précède longtemps DOS. Il provient des poinçons de carte, qui étaient des appareils à 80 colonnes.

Et pour répondre en quelque sorte à la question du PO, une «étude» est en cours depuis environ 600 ans maintenant - le livre imprimé. Celles-ci ont évolué au fil des siècles, avec la lisibilité avant tout à l'esprit, à la position où nous en sommes maintenant où la longueur moyenne de ligne pour le texte est d'environ 60 caractères. Donc, pour la lisibilité, optez pour des marges plus étroites.

85

Je ne crois vraiment pas que vous puissiez comparer la lecture d'un langage naturel à la lecture d'un langage de programmation en termes de convivialité.

— Vendredi

25

@Frug - en fait, vous le pouvez probablement. La raison de la largeur de 65 caractères n'est pas parce que les lignes plus grandes ne peuvent pas être lues, mais que c'est un arc trop serré lorsque l'œil passe à la ligne suivante. Vous pouvez contourner cela en augmentant la hauteur de la ligne, mais cela rend plus difficile l'utilisation de l'espacement des blocs pour transmettre du sens, c'est donc probablement quelque chose à éviter dans un IDE.

— Jimmy Breck-McKye

32

@Jim - Mon langage naturel ne contient pas de mots avec 30 caractères (pas que j'utilise de toute façon) et il analyse complètement différemment d'un langage de programmation. Vous pouvez souvent regrouper une ligne de code séparément du reste, qu'il s'agisse d'un long conditionnel ou d'une combinaison de méthodes et de classes longues. Combinez cela avec une indentation et la comparaison entre les deux langues devient absurde. Je ne doute pas que quiconque étudie scientifiquement la lisibilité et la longueur des lignes s'opposerait à ce que vous analysiez les différences.

— Frug

10

@Frug - Je ne vois pas vraiment comment vos objections interagissent avec l'une des revendications que j'ai faites, mais je peux voir que l'indentation rompt le modèle que je propose. Mais ne m'appelez pas «Jim».

— Jimmy Breck-McKye

17

Un livre est généralement placé beaucoup plus près des yeux qu'un moniteur, ce qui signifie que moins de caractères par ligne sont autorisés si le lecteur doit pouvoir lire le livre sans avoir à se tordre le cou. Un écran n'est généralement pas placé à la distance d'un livre, ce qui signifie que plus de caractères par ligne peuvent être utilisés tout en restant dans les limites de l'angle maximal de l'œil. De plus, le code n'est pas lu autant qu'il est lu, ce qui rend cette largeur moins importante. Je (YMMV) peut facilement suivre des lignes de 120 caractères de code sur l'écran de mon ordinateur portable, mais c'est trop large pour 2 tampons emacs sur mon ordinateur portable 15 ", hélas.

— Obscaenvs

104

Ayez pitié des programmeurs qui doivent maintenir votre logiciel plus tard et respectez une limite de 80 caractères.

Raisons de préférer 80:

Lisible avec une police plus grande sur les ordinateurs portables
Laisse de l'espace pour mettre deux versions côte à côte à des fins de comparaison
Laisse de l'espace pour les vues de navigation dans l'EDI
Imprime sans couper arbitrairement les lignes (s'applique également aux e-mails, pages Web, ...)
Limite la complexité en une seule ligne
Limite l'indentation qui à son tour limite la complexité des méthodes / fonctions

Oui, cela devrait faire partie de la norme de codage.

— starblue
source

10

Ce sont de bonnes raisons de garder la largeur de ligne à 80 caractères ou moins. Je suis vraiment surpris (déçu) que votre réponse, qui est clairement réfléchie et correcte, n'ait pas obtenu plus de points. À cette liste, j'ajouterais: (1) le défilement horizontal n'est pas amusant. (2) Vous pouvez augmenter considérablement la densité du code sur lequel vous travaillez en affichant ce code dans plusieurs colonnes. Une grande partie de l'immobilier est gaspillée lorsque vous avez quelques lignes qui s'étendent loin vers la droite alors que la plupart des autres lignes ne le sont pas.

— Donnie Cameron du

4

ok mais que se passe-t-il quand il y a un bloc de code avec peu d'indentations? cela m'est arrivé et 80 personnages ne sont pas du tout amusants.

— EKanadily

14

Limits the complexity in one lineJe ne sais pas pourquoi il est préférable de répartir la complexité sur plusieurs lignes. Cela pousse simplement plus sur votre pile mentale.

— Jonathan

4

C'est un sujet très ancien. mais êtes-vous toujours d'accord maintenant que de nombreux développeurs utilisent des moniteurs 27 pouces :-). Je veux dire que si la vue est un problème, un écran plus grand peut aider. Il y a 8 ans, nous travaillions encore sur des moniteurs 17 ou 20 pouces et certains sur des résolutions 4: 3 même.

— Mathijs Segers

1

@MathijsSegers, quelle que soit la taille ou la résolution de l'écran, il est toujours plus confortable de garder le texte au milieu de 30 degrés de votre champ de vision. Lorsque je travaille avec plusieurs fenêtres ouvertes dans des moniteurs côte à côte, j'ai tendance à tourner la tête pour regarder de l'un à l'autre. Une personne ne devrait pas avoir à tourner la tête ou à tourner complètement les yeux pour lire d'un bout à l'autre d'une ligne. Une telle rotation rapide des yeux ou de la tête causerait probablement des vertiges si elle était effectuée toute la journée.

— maurice

41

Je n'ai pas d'études, mais je raconterai mon expérience.

Je trouve que le défilement horizontal est fastidieux lorsqu'il s'agit de texte. Je regarde l'environnement dans lequel le code sera utilisé et je fixe des normes de largeur basées sur ce contexte.

Par exemple, lorsque je travaillais dans Emacs sur XWindows, cela fonctionnait bien d'avoir 2 fenêtres Emacs côte à côte à tout moment. Cela les limitait à 80 caractères, c'était donc ma longueur de ligne maximale.

À un moment donné, j'ai travaillé dans Visual Studio sur un écran 1920x1200. Je le garderais maximisé, avec toutes les fenêtres d'outils ancrées d'un côté. Il restait suffisamment d'espace pour deux fenêtres d'édition côte à côte à environ 100 caractères.

Je trouve également que les lignes les plus longues proviennent d' appels de méthode avec de longues listes de paramètres . C'est parfois une odeur de code : peut-être que la méthode devrait être refactorisée .

Si vous et vos co-programmeurs avez des écrans haute résolution et une vue nette, utilisez certainement une petite police et de longues lignes. Inversement, vous pouvez avoir besoin de lignes courtes.

— Jay Bazuzi
source

1

plus un pour les "yeux vifs" car c'est vraiment ce qui m'est arrivé.

— EKanadily

26

J'utilise normalement 120-150, sauf indication contraire de la société. Cependant cela dépend aussi du type de code:

Je n'utilise (presque) jamais plusieurs instructions sur une seule ligne
Je n'utilise de longues lignes (> 12) que si des lignes qui se ressemblent peuvent être alignées et non cassées.
J'utilise toujours suffisamment d'espaces / parenthèses, etc.
Je préfère les noms de variables plus longs au-dessus des noms plus courts

Jusqu'à il y a quelques années, je limitais à 100 mais maintenant les écrans larges sont normalement utilisés et les moniteurs haute résolution 120 peuvent même être vus sur les ordinateurs portables (que j'utilise à peine).

Comparer un écran à un livre n'est pas vraiment bien car un livre a plus d'espace vertical et un écran a plus d'espace horizontal. J'essaye toujours de garder une fonction max. un écran visible de long.

— Michel Keijzers
source

6

Comment fonctionne 120-150 caractères par ligne avec plusieurs fenêtres ouvertes côte à côte? Gardez-vous de nombreuses fenêtres d'éditeur de code ouvertes côte à côte? - Sur mon moniteur 30 '', je peux avoir 3 fenêtres côte à côte, si je limite mes lignes à 97 caractères / ligne.

— KajMagnus

1

Je code sur un grand écran et j'aime aussi des quantités plus importantes. Je vise 110-130. L'un de mes principaux objectifs est la lisibilité et la division des déclarations en 2-3 lignes est parfois moins lisible à mon avis. Je vais aussi parfois aller à 500-1000 pour cacher les indésirables que je ne veux pas voir, tels que certains commentaires, le code désactivé et certaines valeurs codées en dur. Je pense que cela dépend aussi du programmeur. Si la plupart des codeurs fonctionnent à 80, il est préférable de viser cela lorsque vous travaillez avec du code partagé.

— Sunsetquest

10

Peut-être que les 80 caractères sont également un bon point pour éviter ces mauvaises chaînes getter:

object.getFoo().getBar().getFooBar().get ...

si vous le limitez à 80 caractères, peut-être que quelqu'un localiserait ces variables et ferait une vérification nulle, etc., mais peut-être que la plupart des programmeurs les laisseraient encapsuler dans la ligne suivante. Je ne sais pas

À côté de cela, 80 caractères sont excellents comme starblue mentionné. Cela devrait définitivement entrer dans les normes de codage.

— Christopher Klewes
source

5

Pour info, un enchaînement excessif de méthodes comme celui-ci est connu sous le nom d' anti-modèle d'épave de train .

— Dennis

4

Sans tenir compte des restrictions matérielles et des différences dans la façon dont nous lisons le code par rapport au langage naturel, je vois trois raisons principales pour limiter les lignes à environ 80 caractères.

Les globes oculaires humains sont ronds, pas vraiment étroits et larges, et la plupart de leur résolution est au milieu . Lorsque vous lisez pendant des heures à la fois, il est beaucoup plus confortable de balayer les yeux dans de courts arcs, en utilisant une barre de défilement si nécessaire. Je ne connais pas d'étude formelle spécifique à la lisibilité du code, mais d'après mes propres observations, avec le moniteur à 2 mètres de distance, avec du texte dimensionné avec une police à espacement unique de 10 points, 100 caractères occupent environ 1/3 de mon champ horizontal de vision, ou autour de 60 degrés (en dehors des 30 degrés environ où la résolution de tous nos yeux est à ).
La plupart des gens utilisent un grand écran au travail afin de pouvoir voir plusieurs choses sans cliquer d'avant en arrière, pas pour voir une chose vraiment grande.
Les lignes plus courtes contiennent moins de complexité, ce qui, espérons-le, oblige un développeur à décomposer son code en unités plus digestes.

— maurice
source

3

Je me souviens distinctement avoir lu quelque part (je pense que c'était dans la documentation Agile ) que pour une lisibilité optimale, la largeur d'un document devrait être d'environ deux alphabets, soit 60 à 70 caractères. Je pense que la largeur de ligne des anciens terminaux venait en partie de cette vieille règle typographique.

— Lindelof
source

3

L'option de marge de droite est destinée à vous montrer la largeur de la page si vous allez imprimer le code, et a déjà annoncé qu'elle était définie sur 80 parce que c'est ce que la longueur de la ligne était historiquement avant l'interface graphique. cartes.

J'ai récemment vu une recommandation sur un blog (je ne me souviens plus de quel blog) pour augmenter la taille de la police de votre IDE afin d'améliorer la qualité du code, la logique derrière cela est que si moins de code tient à l'écran, vous écrirez des lignes plus courtes et fonctions de shouter.

À mon avis, des lignes plus courtes facilitent la lecture du code et le débogage, alors j'essaie de garder les lignes courtes, si vous devez définir une limite pour vous permettre d'écrire un meilleur code, choisissez ce qui fonctionne pour vous - même si vous êtes plus productif avec des lignes plus longues, n'hésitez pas à augmenter la taille de la page et le code uniquement sur un écran large.

— Nir
source

1

Comme certains l'ont souligné dans d'autres réponses, la raison de la limite de 80 caractères est en partie historique (cartes perforées, petits écrans, imprimantes, etc.) et en partie biologique (pour suivre dans quelle ligne vous vous trouvez, il est généralement bon de pouvoir voir l'intégralité de la ligne. ligne sans avoir besoin de tourner la tête).

Cela dit, rappelez-vous que nous sommes toujours des humains et que nous construisons des outils pour résoudre nos propres limites. Je vous propose d'ignorer tout le débat sur la limitation des caractères et d'écrire simplement des choses qui ont du sens quelle que soit leur longueur, et d'utiliser un IDE ou un éditeur de texte qui peut vous aider à suivre correctement les lignes. En utilisant le même argument pour l'indentation dans le débat onglets vs espaces, ainsi que la largeur des indentations, je vous propose d'utiliser un marqueur d'indentation (le plus souvent l'onglet) et de laisser les gens configurer leur propre IDE ou éditeurs de texte pour les afficher comme ils le trouvent le plus confortable pour eux.

S'en tenir à un nombre fixe de caractères par ligne aggravera toujours les choses pour tout le monde sauf le public ciblé. Cela dit, si vous ne partagerez jamais le code, jamais; alors il n'y a vraiment aucune raison d'avoir même cette discussion pour commencer. Si vous souhaitez partager le code, vous devriez probablement laisser les gens décider eux-mêmes de ce qu'ils veulent au lieu de leur imposer les vôtres (ou ceux de quelqu'un d'autre).

— Jonas Lihnell
source

0

À ma connaissance, le caractère 80 est utilisé comme norme de codage pour maintenir la compatibilité avec les éditeurs de ligne de commande (la largeur par défaut du terminal est généralement de 80 caractères). Avec les IDE modernes et les résolutions grand écran, 80 caractères ne sont probablement pas "optimaux", mais pour de nombreux développeurs, il est essentiel de maintenir la lisibilité dans le terminal. Pour cette raison, il est peu probable que la largeur de 80 caractères soit bientôt remplacée en tant que norme de facto pour la largeur de code. Et pour répondre à votre dernière question, oui, la largeur du code ainsi que toute autre caractéristique qui affectera la lisibilité de votre code doivent être traitées dans vos normes de codage.