Des études sur la largeur de code optimale?
Si vous activez la "View Right Margin" dans votre IDE de votre choix, il est probable qu'il sera par défaut à 80 caractères. J'ai tendance à le changer à 120 pour aucune autre raison que c'était le standard dans une entreprise avec laquelle j'étais il y a quelques années, et aucune autre entreprise ne m'a dit de le faire différemment.
Ma question est, y a-t-il des études qui montrent en fait que 80 caractères sont la largeur maximale optimale pour la lisibilité du code, ou est-ce que cette valeur est juste "c'est comme ça que ça a toujours été" et personne ne sait vraiment pourquoi il en 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. Cela vient des cartes perforées, 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 - le livre imprimé. Celles-ci ont évolué au fil des siècles, en gardant à l'esprit la lisibilité, jusqu'à la position actuelle où la longueur moyenne des lignes de texte est d'environ 60 caractères. Donc pour la lisibilité, optez pour des marges plus étroites.
Ayez pitié des programmeurs qui doivent entretenir 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 pour comparaison
Laisse de l'espace pour les vues de navigation dans l'EDI
Imprime sans interrompre 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 vais raconter 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 en fonction de 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 y avait suffisamment d'espace pour deux fenêtres d'éditeur côte à côte avec environ 100 caractères.
Je trouve également que les lignes les plus longues proviennent de appels de méthode avec de longues listes de paramètres. C'est parfois un 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 aurez peut-être 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 les 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 aux noms plus courts
Jusqu'à il y a quelques années, je me 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 bon car un livre a plus d'espace vertical et un écran a plus d'espace horizontal. J'essaie 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
En plus de cela, 80 caractères sont excellents, comme l'a mentionné Starblue. Cela devrait sans aucun doute entrer dans les normes de codage.
Je me souviens distinctement avoir lu quelque part (je pense que c'était dans Agile Documentation ) que pour une lisibilité optimale, la largeur d'un document devrait être d'environ deux alphabets, ou 60-70 caractères. Je pense que la largeur de ligne des anciens terminaux provenait en partie de cette ancienne 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 précédemment indiqué qu'il était réglé sur 80 car c'est ce que la longueur de la ligne était historiquement avant l'interface graphique tout au long du processus de punch cartes.
J'ai récemment vu une recommandation sur un blog (je ne me souviens pas de quel blog) pour vous augmenter IDE taille de police 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 des fonctions de shouter.
À mon avis, des lignes plus courtes facilitent la lecture du code et le débogage, donc j'essaie de garder les lignes courtes, si vous devez définir une limite pour vous permettre d'écrire un meilleur code, puis choisissez ce qui fonctionne pour vous - également si vous êtes plus productif avec des lignes plus longues se sentent libres d'augmenter la taille de la page et le code uniquement sur des écrans larges.
Sans tenir compte des restrictions matérielles et de toute différence dans la façon dont nous lisons le code par rapport au langage naturel, je vois trois principales raisons de 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 milie . Lors de la lecture pendant des heures, il est beaucoup plus confortable de balayer les yeux en petits arcs, en utilisant une barre de défilement au besoin. Je ne connais pas d'étude formelle spécifique à la lisibilité du code, mais d'après mes propres observations, avec le moniteur à 2 pieds de distance, avec du texte de taille à une police espacée de 10pt, 100 caractères occupent environ 1/3 de mon champ horizontal de vision, ou environ 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 pour 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, force un développeur à diviser son code en unités plus digestes.
Comme certaines personnes 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é du sans avoir besoin de tourner la tête).
Cela dit, n'oubliez pas que nous sommes toujours des humains et que nous créons 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 trucs qui ont du sens quelle que soit leur longueur, et d'utiliser un IDE ou un éditeur de texte qui peut vous aider à garder une trace correcte des 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 des éditeurs de texte pour les afficher à leur guise.
S'en tenir à un nombre fixe de caractères par ligne ne fera qu'empirer les choses pour tout le monde sauf pour le public cible. 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 ce qu'ils veulent au lieu de leur imposer vos idéaux (ou 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 du terminal par défaut est généralement de 80 caractères). Avec les IDE modernes et les grandes résolutions d'écran, 80 caractères n'est probablement pas "optimal", mais pour de nombreux développeurs, la lisibilité du terminal est essentielle. Pour cette raison, il est peu probable que la largeur de 80 caractères soit remplacée prochainement comme standard de facto pour la largeur du 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.