Des études sur la largeur de code optimale?

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?

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.

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.

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.

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.

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.

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.

1. 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 à ).
2. 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.
3. 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.

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.

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.

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).

À 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.