Des études sur un code optimal de la largeur?

Question

Si vous activez la fonction "Vue de la Marge de Droite" dans votre IDE de choix, il est probable qu'il sera par défaut à 80 caractères. J'ai tendance à changer à 120 pour aucune autre raison que c'était la norme à une société, j'étais avec quelques années en arrière, et aucune autre entreprise m'a dit de le faire différemment.

Ma question est, existe-il des études qui fait de montrer de 80 caractères, une meilleure largeur maximale pour la lisibilité du code, ou est-ce juste valeur d'un "c'est la façon dont il a toujours été" et personne ne sait vraiment pourquoi c'est de cette façon? Et, si la largeur d'une ligne de code dans votre norme de codage?

Answer 1

Pitié pour les programmeurs qui ont à maintenir votre logiciel plus tard et s'en tenir à une limite de 80 caractères.

Les raisons de préférer 80:

• Lisible avec une police plus grande sur les ordinateurs portables

• Laisse de la place pour mettre les deux versions côte à côte pour la comparaison

• Laisse de l'espace pour les affichages de navigation dans l'IDE

• Imprime sans arbitrairement à casser des lignes (s'applique également à l'email, pages web, ...)

• Les limites de la complexité dans une ligne

• Les limites de l'indentation qui à son tour les limites de la complexité des méthodes / fonctions

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

Answer 2

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

Je trouve que le défilement horizontal est fastidieux lorsque l'on traite avec le texte. Je regarde l'environnement que le code sera utilisé, et de mettre la largeur des normes basées sur le contexte.

Par exemple, lorsque j'ai travaillé dans Emacs sur XWindows, il a bien fonctionné pour avoir 2 Emacs fenêtres côte-à-côte en tout temps. Que de les limiter à 80 caractères, de sorte que c'était mon max de longueur de ligne.

À un moment, j'ai travaillé dans Visual Studio sur un 1920x1200 écran. J'aimerais le garder agrandie, avec toutes les fenêtres d'outils ancrée sur un côté. Il y avait assez de place pour deux fenêtres côte-à-côte aux alentours de 100 caractères.

Je trouve aussi que le plus long des lignes proviennent les appels de méthode avec de longues listes de paramètres. C'est parfois une odeur de code: peut-être la méthode doit être remaniée.

Si vous et votre co-programmeurs ont des écrans haute résolution et forte de la vue, par tous les moyens d'utiliser une petite police et les longues lignes. À l'inverse, vous pouvez avoir besoin de courtes lignes.

Answer 3

J'utilise normalement de 120 à 150, à moins que l'entreprise décrit autrement. Toutefois, cela dépend aussi du type de code:

• J'ai (presque) jamais utiliser plusieurs instructions sur une seule ligne
• Je n'utilise que des lignes longues (>12) seulement si les lignes qui ressemblent peut être aligné et ne se décompose pas.
• J'utilise toujours assez de places/parenthèse etc
• Je préfère plus des noms des variables ci-dessus de noms plus courts

Jusqu'à il y a quelques années j'ai limité à 100, mais maintenant écrans larges sont normalement utilisés et de haute résolution des moniteurs 120 peut être vu sur les ordinateurs portables (que j'ai de la peine à utiliser).

La comparaison d'un écran à un livre n'est pas vraiment bon, parce qu'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.

Answer 4

Peut-être que le 80 caractères est également un bon point pour éviter ces mauvais getter chaînes:

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

si vous limiter à 80 caractères, peut-être quelqu'un serait de localiser ces variables et ne font nulle vérification, etc, mais peut-être que la plupart des programmeurs serait de les laisser envelopper dans la ligne suivante. je ne sais pas

A côté de cela, de 80 caractères sont grands comme starblue mentionné. Cela devrait defenitely va dans les normes de codage.