Existe-t-il une raison valable pour appliquer une largeur maximale de 80 caractères dans un fichier de code, de nos jours?
Sérieusement. Sur un moniteur 22 ", il ne couvre peut-être qu'un quart de l'écran. J'ai besoin de munitions pour abattre cette règle.
Je ne dis pas qu'il ne devrait pas y avoir de limite; Je dis juste, 80 caractères est très petit.
Je pense que la pratique consistant à conserver le code sur 80 (ou 79) colonnes a été créée à l'origine pour aider les personnes à modifier le code sur des terminaux muets à 80 colonnes ou sur des impressions à 80 colonnes. Ces exigences ont pour la plupart disparu maintenant, mais il existe encore des raisons valables de conserver la règle des 80 colonnes:
- Pour éviter le wrapping lors de la copie de code dans des e-mails, des pages Web et des livres.
- Pour afficher plusieurs fenêtres source côte à côte ou à l'aide d'une visionneuse de différences côte à côte.
- Pour améliorer la lisibilité. Le code étroit peut être lu rapidement sans avoir à balayer vos yeux d'un côté à l'autre.
Je pense que le dernier point est le plus important. Bien que la taille et la résolution des écrans aient augmenté ces dernières années, les yeux ne l'ont pas.
L'origine du formatage de texte à 80 colonnes est antérieure aux terminaux à 80 colonnes - la carte perforée IBM remonte à 1928 ! Cela rappelle l'histoire (apocryphe) que le gabarit ferroviaire américain était déterminé par la largeur des roues de char en Grande-Bretagne romaine.
Je trouve parfois cela un peu contraignant, mais il est logique d'avoir une limite standard , donc 80 colonnes.
Voici le même sujet couvert par Slashdot .
Et voici une déclaration de Fortran à l'ancienne:
80 caractères est une limite ridicule de nos jours. Fractionnez vos lignes de code là où cela a du sens, et non selon une limite de caractères arbitraire.
Vous devriez le faire pour le bien de tous ceux qui n'ont pas de moniteur à écran large de 22 pouces. Personnellement, je travaille sur un moniteur 17 pouces 4: 3, et je trouve cela plus que suffisamment large. Cependant, j'ai également 3 de ces moniteurs, donc j'ai encore beaucoup d'espace d'écran utilisable.
Non seulement cela, mais l'œil humain a en fait des problèmes de lecture de texte si les lignes sont trop longues. Il est trop facile de se perdre dans quelle ligne vous vous trouvez. Les journaux ont 17 pouces de diamètre (ou quelque chose comme ça), mais vous ne les voyez pas écrire tout au long de la page, il en va de même pour les magazines et autres articles imprimés. Il est en fait plus facile à lire si vous gardez les colonnes étroites.
Lorsque vous avez une séquence d'instructions qui se répètent avec des variations mineures, il peut être plus facile de voir les similitudes et les différences si elles sont regroupées en lignes de sorte que les différences s'alignent verticalement.
Je dirais que ce qui suit est beaucoup plus lisible qu'il ne l'aurait été si je l'avais divisé sur plusieurs lignes:
switch(Type) {
case External_BL: mpstrd["X"] = ptDig1.x - RadialClrX; mpstrd["Y"] = ptDig1.y - RadialClrY; break;
case External_BR: mpstrd["X"] = ptDig1.x + RadialClrX; mpstrd["Y"] = ptDig1.y - RadialClrY; break;
case External_TR: mpstrd["X"] = ptDig1.x + RadialClrX; mpstrd["Y"] = ptDig1.y + RadialClrY; break;
case External_TL: mpstrd["X"] = ptDig1.x - RadialClrX; mpstrd["Y"] = ptDig1.y + RadialClrY; break;
case Internal_BL: mpstrd["X"] = ptDig1.x + RadialClrX; mpstrd["Y"] = ptDig1.y + RadialClrY; break;
case Internal_BR: mpstrd["X"] = ptDig1.x - RadialClrX; mpstrd["Y"] = ptDig1.y + RadialClrY; break;
case Internal_TR: mpstrd["X"] = ptDig1.x - RadialClrX; mpstrd["Y"] = ptDig1.y - RadialClrY; break;
case Internal_TL: mpstrd["X"] = ptDig1.x + RadialClrX; mpstrd["Y"] = ptDig1.y - RadialClrY; break;
}
pdate: Dans le commentaire, il a été suggéré que ce serait une façon plus succincte de faire ce qui précède:
switch(Type) {
case External_BL: dxDir = - 1; dyDir = - 1; break;
case External_BR: dxDir = + 1; dyDir = - 1; break;
case External_TR: dxDir = + 1; dyDir = + 1; break;
case External_TL: dxDir = - 1; dyDir = + 1; break;
case Internal_BL: dxDir = + 1; dyDir = + 1; break;
case Internal_BR: dxDir = - 1; dyDir = + 1; break;
case Internal_TR: dxDir = - 1; dyDir = - 1; break;
case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY;
même si elle tient maintenant dans 80 colonnes, je pense que mon point est toujours valable et je viens de choisir un mauvais exemple. Il démontre toujours que placer plusieurs instructions sur une ligne peut améliorer la lisibilité.
L'impression d'une police à espacement fixe aux tailles par défaut est (sur papier A4) 80 colonnes par 66 lignes.
J'utilise l'avantage d'écrans plus grands pour avoir plusieurs morceaux de code côte à côte.
Vous ne recevrez pas de munitions de ma part. En fait, je détesterais le voir changer car en cas d'urgence, je vois encore de rares cas où je dois changer de code à partir d'une console texte.
Les très longues lignes sont plus difficiles à lire. Ce n'est pas parce que vous pouvez afficher 300 caractères sur votre moniteur que vous devez allonger les lignes. 300 caractères est également beaucoup trop complexe pour une déclaration à moins que vous n'ayez pas le choix (un appel qui a besoin de tout un tas de paramètres.)
J'utilise 80 caractères en règle générale, mais j'irai au-delà si appliquer cela signifierait de mettre un saut de ligne à un endroit indésirable.
La seule chose que j'impose pour rester dans les 80 caractères est mon commentaire.
Personnellement ... je consacre toute ma puissance cérébrale (le peu qu'il y a) au bon codage, c'est pénible de devoir revenir en arrière et tout casser à la limite de 80 caractères quand je pourrais passer mon temps sur la fonction suivante . Oui, Resharper pourrait le faire pour moi, je suppose, mais cela me fait un peu peur qu'un produit tiers prenne des décisions sur la disposition de mon code et le change ("S'il vous plaît, ne divisez pas mon code en deux lignes HAL. HAL?" ).
Cela dit, je travaille dans une équipe assez petite et tous nos moniteurs sont assez grands, donc s'inquiéter de ce qui dérange mes collègues programmeurs n'est pas une énorme préoccupation pour autant.
Il semble que certaines langues encouragent des lignes de code plus longues pour plus de rentabilité (instructions courtes si puis).
J'ai deux moniteurs 20 "1600x1200 et je m'en tiens à 80 colonnes car cela me permet d'afficher plusieurs fenêtres d'éditeur de texte côte à côte. En utilisant la police '6x13' (la police trad. Xterm), 80 colonnes occupent 480 pixels plus la barre de défilement et les bordures de fenêtres. Cela permet d'avoir trois fenêtres de ce type sur un moniteur 1600x1200. Sur les fenêtres, la police Lucida Console ne fera pas tout à fait cela (la taille minimale utilisable est de 7 pixels de large) mais un moniteur 1280x1024 affichera deux colonnes et un moniteur 1920x1200 tel qu'un HP LP2465 affichera 3. Il laissera également un peu de place sur le côté pour les divers explorateurs, propriétés et autres fenêtres de Visual Studio.
De plus, de très longues lignes de texte sont difficiles à lire. Pour le texte, l'optimum est de 66 caractères. Il y a un point où les identifiants excessivement longs commencent à être contre-productifs car ils rendent difficile la présentation cohérente du code. Une bonne mise en page et une indentation fournissent des repères visuels quant à la structure du code et certains langages (Python me vient à l'esprit) utilisent explicitement l'indentation pour cela.
Cependant, les bibliothèques de classes standard pour Java et .Net ont tendance à avoir une prépondérance d’identifiants très longs, donc on ne peut pas nécessairement garantir de pouvoir le faire. Dans ce cas, la disposition du code avec la ligne -breaks aide toujours à rendre la structure explicite.
Notez que vous pouvez obtenir des versions Windows des polices '6x13' ici .
Les autres réponses ont déjà bien résumé les choses, mais cela vaut également la peine de considérer quand vous voudrez peut-être copier-coller du code dans un e-mail, ou sinon du code, puis un diff.
C'est un moment où avoir une "largeur max" est utile.
Vous n'êtes pas la seule personne à conserver votre code.
La prochaine personne qui possède peut avoir un écran de 17 "ou peut avoir besoin de grandes polices pour lire le texte. La limite doit être quelque part et 80 caractères est la convention en raison des limitations d'écran précédentes. Pouvez-vous penser à une nouvelle norme (120) et pourquoi c'est une bonne idée d'utiliser cet autre alors "c'est ce qui convient à mon moniteur avec la police Xpt?"
Rappelez-vous, il y a toujours des exceptions à chaque règle, donc vous avez une ligne ou un bloc de code particulier qui a du sens d'être plus de 80 caractères, puis d'être un rebelle.
Mais prenez d'abord le temps de penser "ce code est-il vraiment si mauvais qu'il ne peut pas vivre dans les 80 caractères?"
Je me demande si cela pourrait causer plus de problèmes de nos jours. N'oubliez pas qu'en C (et éventuellement dans d'autres langages), il existe des règles pour la durée d'un nom de fonction. Par conséquent, vous voyez souvent des noms très difficiles à comprendre dans le code C. La bonne chose est qu'ils n'utilisent pas beaucoup d'espace. Mais chaque fois que je regarde du code dans un langage comme C # ou Java les noms de méthode sont souvent très longs, ce qui rend presque impossible de garder votre code à une longueur de 80 caractères. Je ne ' Je pense que 80 caractères sont valables aujourd'hui, sauf si vous devez être en mesure d'imprimer le code, etc.
Dans la norme de codage Linux, non seulement ils conservent la limite de 80 caractères, mais ils utilisent également une indentation de 8 espaces.
Une partie du raisonnement est que si jamais vous atteignez la bonne marge, vous devriez envisager de déplacer un niveau d'indentation dans une fonction distincte.
Cela rendra le code plus clair car, quelles que soient les longueurs d'indentation, il est plus difficile de lire le code avec de nombreuses structures de contrôle imbriquées.
J'aime limiter ma largeur à 100 caractères environ pour permettre à deux éditeurs SxS sur un écran large. Je ne pense pas qu'il y ait de bonnes raisons pour une limite d'exactement 80 caractères.
Comme d'autres l'ont dit, je pense qu'il est préférable de (1) imprimer et (2) afficher plusieurs fichiers côte à côte verticalement.
En tant qu'auteur des directives de codage pour mon employeur, j'ai augmenté la longueur de ligne de 80 à 132. Pourquoi cette valeur? Eh bien, comme d'autres l'ont souligné, 80 est la longueur de nombreux anciens terminaux matériels. Et 132 l'est aussi! C'est la largeur de ligne lorsque les terminaux sont en mode large . Toute imprimante peut également faire des copies papier en mode large avec une police condensée.
La raison de ne pas rester à 80 est que je préfère
- préférez des noms plus longs avec une signification pour les identifiants
- ne vous embêtez pas avec les typedefs pour les structures et les énumérations en C (ils sont MAUVAIS, ils CACHENT des informations utiles! Demandez à Peter van der Linden dans "Deep C Secrets" si vous ne le croyez pas), donc le code a plus de
struct FOO func(struct BAR *aWhatever, ...)que le code des fanatiques de typedef.
et selon ces règles, seulement 80 caractères/ligne provoquent des retours à la ligne laids plus souvent que mes yeux ne le jugent acceptable (principalement dans les prototypes et les définitions de fonctions).
Utilisez des polices proportionnelles.
Je suis serieux. Je peux généralement obtenir l'équivalence de 100 à 120 caractères sur une ligne sans sacrifier la lisibilité ou l'imprimabilité. En fait, il est encore plus facile de lire avec une bonne police (par exemple, Verdana) et une coloration syntaxique. Ça a l'air un peu étrange pendant quelques jours, mais on s'y habitue vite.
Les gens disent que les longues lignes de code ont tendance à être complexes. Considérons une simple classe Java classe:
public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {
Il contient 94 caractères et le nom de la classe est assez court (selon les normes GWT). Il serait difficile de lire sur 2 lignes et il est très lisible sur une seule ligne. Étant pragmatique à ce sujet et permettant ainsi une "rétrocompatibilité", je dirais que 100 caractères est la bonne largeur.
J'ai élargi mon code à 100 caractères, ce qui tient confortablement dans moins de la moitié de mon écran sur mon Macbook. 120 caractères est probablement la limite avant que les lignes ne deviennent trop longues et complexes. Vous ne voulez pas être trop large sinon vous encouragez les instructions composées et les structures de contrôle profondément imbriquées.
La marge de droite est la manière naturelle de vous dire d'effectuer une refactoring de méthode supplémentaire .
Je pense que le fait de ne pas appliquer 80 caractères signifie éventuellement un habillage Word.
IMO, toute longueur choisie pour une ligne de largeur maximale n'est pas toujours appropriée et le retour à la ligne devrait être une réponse possible.
Et ce n'est pas aussi simple qu'il y paraît.
Il est implémenté dans jedit 
(source: jedit.org ) qui propose un retour à la ligne
Mais c'est amèrement raté dans Eclipse depuis très longtemps ! (depuis 2003 en fait), principalement parce qu'un habillage Word pour éditeur de texte implique:
- Les informations de ligne enveloppée sont destinées à la visionneuse de texte, à la navigation par code et aux règles verticales.
- Des informations de ligne non enveloppées sont requises pour des fonctionnalités telles que la ligne goto, la colonne de la règle de numérotation des lignes, la surbrillance de la ligne actuelle, le fichier de sauvegarde.
J'essaie de limiter les choses à près de 80 caractères pour une raison simple: trop plus que cela signifie que mon code devient trop compliqué. Les noms de propriété/méthode trop verbeux, les noms de classe, etc. causent autant de dégâts que les noms laconiques.
Je suis principalement un codeur Python, donc cela produit deux ensembles de limitations:
- N'écrivez pas de longues lignes de code
- Ne pas trop indenter
Lorsque vous commencez à atteindre deux ou trois niveaux d'indentation, votre logique devient confuse. Si vous ne pouvez pas garder un seul bloc sur la même page, votre code devient trop compliqué et difficile à retenir. Si vous ne pouvez pas garder une seule ligne dans les 80 caractères, votre ligne devient trop compliquée.
Il est facile en Python d'écrire du code relativement concis (voir codegolf) au détriment de la lisibilité, mais il est encore plus facile d'écrire du code verbeux au détriment de la lisibilité. Les méthodes d'aide ne sont pas une mauvaise chose, les classes auxiliaires non plus. Une abstraction excessive peut être un problème, mais c'est un autre défi de la programmation.
En cas de doute dans un langage comme C, écrivez des fonctions d'aide et insérez-les si vous ne voulez pas la surcharge d'appeler une autre fonction et de revenir en arrière. Dans la plupart des cas, le compilateur traitera les choses intelligemment pour vous.
Il y a déjà beaucoup de bonnes réponses à cela, mais il convient de mentionner que dans votre IDE vous pourriez avoir une liste de fichiers à gauche et une liste de fonctions à droite (ou tout autre) configuration).
Votre code n'est qu'une partie de l'environnement.
Oui, car même de nos jours, certains d'entre nous codent sur des terminaux (ok, principalement des émulateurs de terminaux), où l'affichage ne peut afficher que 80 caractères. Donc, au moins pour le codage que je fais, j'apprécie vraiment la règle des 80 caractères.
En fait, je suis une règle similaire pour mon propre code, mais uniquement en raison de l'impression du code sur une page A4 - 80 colonnes est à peu près la bonne largeur pour la taille de police souhaitée.
Mais c'est une préférence personnelle et probablement pas ce que vous recherchiez (puisque vous voulez que les munitions partent dans l'autre sens).
Que ne remettez-vous pas en cause le raisonnement derrière la limite - sérieusement, si personne ne peut trouver une bonne raison pour laquelle il en est ainsi, vous avez de bonnes raisons de le retirer de vos normes de codage.
Je diffère côte à côte toute la journée et je n'ai pas de moniteur de 22 pouces. Je ne sais pas si je le ferai jamais. Ceci, bien sûr, est peu intéressant pour les programmeurs en écriture seule qui apprécient le codage en flèche et les lignes de 300 caractères.
J'essaie de garder mes lignes en dessous de 80 colonnes. La principale raison est que je me retrouve souvent à utiliser grep et less pour parcourir mon code lorsque je travaille sur la ligne de commande. Je n'aime vraiment pas la façon dont les terminaux cassent les longues lignes source (après tout, ils ne sont pas faits pour ce travail). Une autre raison est que je trouve que ça a l'air mieux si tout rentre dans la ligne et n'est pas cassé par l'éditeur. Par exemple, avoir des paramètres d'appels de fonction longs bien alignés les uns sur les autres et des choses similaires.
Je force mes élèves à se resserrer dans 80 colonnes afin que je puisse imprimer leur code et le marquer .
Et il y a environ 17 ans, j'ai laissé mon propre code s'étendre à 88 colonnes, car j'ai commencé à tout faire en utilisant Noweb et 88 colonnes est ce qui tient dans un document bien imprimé utilisant TeX.
Je ne marque que de deux espaces, mais la pièce supplémentaire est magnifique.
Briser à 80 caractères est quelque chose que vous faites tandis que codage, pas après. Même chose avec les commentaires, bien sûr. La plupart des éditeurs peuvent vous aider à voir où se situe la limite de 80 caractères.
(Cela peut être un peu OT, mais dans Eclipse, il y a une option qui formate le code lorsque vous l'enregistrez (selon les règles que vous voulez). C'est un peu bizarre au début, mais après un certain temps, vous commencez à accepter que le le formatage n'est pas plus entre vos mains que le code généré.)
Si nous avions l'un de ceux-ci , nous n'aurions pas cette discussion! ;-)
Mais sérieusement, les questions que les gens ont soulevées dans leurs réponses sont tout à fait légitimes. Cependant, l'affiche originale ne plaidait pas contre une limite, simplement que 80 colonnes, c'est trop peu.
La question des extraits de code par courrier électronique a un certain mérite. Mais compte tenu des mauvaises actions que la plupart des clients de messagerie font sur du texte pré-formaté, je pense que le retour à la ligne n'est qu'un de vos problèmes.
En ce qui concerne l'impression, je trouve généralement que 100 lignes de caractères s'adapteront très confortablement sur une page imprimée.
Nous avons récemment effectué une enquête. Presque tout le monde utilise vim à l'intérieur d'un terminal gnome, et si nous faisons une division verticale, le nombre de colonnes est de 78 comme taille de police standard et résolution d'écran 1280x1024.
Nous avons donc tous convenu d'une norme de codage avec un nombre de colonnes (environ) 75 caractères. C'est bon.
Je pense toujours que la limite n'est pas limitée sur la partie visuelle. Bien sûr, les moniteurs et les résolutions sont suffisamment grands pour afficher encore plus de caractères sur une seule ligne de nos jours, mais cela augmente-t-il la lisibilité?
Si la limite est vraiment appliquée, c'est aussi une bonne raison de repenser le code et pas de tout mettre sur une seule ligne. C'est la même chose avec l'indentation - si vous avez besoin de beaucoup de niveaux, votre code doit être repensé.