Existe-t-il une raison valable pour appliquer une largeur maximale de 80 caractères dans un fichier de code, à ce jour? [fermé]

Sérieusement. Sur un moniteur de 22 ", il ne couvre peut-être qu'un quart de l'écran. J'ai besoin de quelques munitions pour abolir cette règle.

Je ne dis pas qu'il ne devrait pas y avoir de limite; Je dis juste que 80 caractères, c'est très petit.

Je pense que la pratique consistant à conserver le code à 80 (ou 79) colonnes a été créée à l'origine pour aider les personnes à éditer du code sur des terminaux stupides à 80 colonnes ou sur des impressions de 80 colonnes. Ces exigences ont pratiquement disparu maintenant, mais il existe encore des raisons valables de conserver la règle des 80 colonnes:

• Pour éviter d'encapsuler 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 en utilisant une visionneuse de différences côte à côte.
• Pour améliorer la lisibilité. Le code étroit peut être lu rapidement sans avoir à scanner vos yeux d'un côté à l'autre.

Je pense que le dernier point est le plus important. Bien que les écrans aient augmenté en taille et en résolution au cours des dernières années, les yeux ne l'ont pas fait .

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) selon laquelle l'écartement des chemins de fer américains était déterminé par la largeur des roues des chars 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 traité par Slashdot .

Et voici une déclaration Fortran à l'ancienne:

80 caractères est une limite ridicule de nos jours. Divisez 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 ne disposent pas d'un écran large 22 pouces. Personnellement, je travaille sur un écran 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 pour lire du texte si les lignes sont trop longues. Il est trop facile de se perdre dans la ligne sur laquelle vous vous trouvez. Les journaux font 17 pouces de diamètre (ou quelque chose comme ça), mais vous ne les voyez pas écrire tout le long de la page, il en va de même pour les magazines et autres articles imprimés. C'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 afin 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;
}

Mise à jour: Dans les commentaires, 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; 

bien qu'il rentre maintenant dans 80 colonnes, je pense que mon point est toujours valable et je viens de choisir un mauvais exemple. Cela démontre toujours que le fait de 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 du papier A4) de 80 colonnes par 66 lignes.

J'utilise l'avantage d'écrans plus grands pour avoir plusieurs morceaux de code côte à côte.

Vous n'obtiendrez aucune munition de ma part. En fait, je détesterais le voir changé car en cas d'urgence, je vois encore de rares cas où j'ai besoin de changer le code à partir d'une console de texte.

Les lignes très longues sont plus difficiles à lire. Ce n'est pas parce que vous pouvez faire passer 300 caractères sur votre moniteur que vous devez faire des lignes aussi longues. 300 caractères est également beaucoup trop complexe pour une instruction, sauf si vous n'avez pas le choix (un appel qui nécessite tout un tas de paramètres.)

J'utilise 80 caractères en règle générale, mais j'irai plus loin que si cela signifiait mettre un saut de ligne dans un endroit indésirable.

La seule chose que j'impose de rester dans les 80 caractères est mon commentaire.

Personnellement ... je consacre toute ma puissance cérébrale (le peu qu'il y a) à bien coder, c'est pénible de devoir tout casser à la limite de 80 caractères alors que 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 modifie ("Veuillez ne pas diviser 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 grande préoccupation pour autant.

Il semble que certains langages encouragent des lignes de code plus longues dans le but d'en avoir plus pour leur argent (instructions courtes if then).

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être. Cela permet d'avoir trois fenêtres de ce type sur un moniteur 1600x1200. Sous Windows, la police Lucida Console ne le fera pas tout à fait (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 moment où des identifiants trop longs commencent à être contre-productifs car ils rendent difficile la présentation cohérente du code. Une bonne disposition et une bonne indentation fournissent des repères visuels sur la structure du code et certains langages (Python vient à l'esprit) utilisent l'indentation explicitement pour cela.

Cependant, les bibliothèques de classes standard pour Java et .Net ont tendance à avoir une prépondérance d'identificateurs très longs, donc on ne peut pas nécessairement garantir de pouvoir le faire. Dans ce cas, la disposition du code avec des sauts de ligne aide toujours à rendre la structure explicite.

Notez que vous pouvez obtenir les versions Windows des polices '6x13' ici .

Les gens disent que les longues lignes de code ont tendance à être complexes. Considérez une classe Java simple:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Cela fait 94 caractères et le nom de la classe est assez court (selon les normes GWT). Ce serait difficile à lire sur 2 lignes et il est très lisible sur une seule ligne. Étant pragmatique à ce sujet et permettant ainsi une "compatibilité ascendante", je dirais que 100 caractères sont la bonne largeur.

Les autres réponses résumaient déjà bien les choses, mais il vaut également la peine de considérer quand vous voudrez peut-être copier et coller du code dans un e-mail, ou si ce n'est pas coder, un diff.

C'est un moment où avoir une "largeur maximale" est utile.

Vous n'êtes pas la seule personne à maintenir votre code.

La personne suivante qui aura peut-être un écran de 17 pouces ou aura 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?"

N'oubliez pas qu'il y a toujours des exceptions à chaque règle, donc si vous avez une ligne ou un bloc de code particulier qui a du sens pour être plus de 80 caractères alors être un rebelle.

Mais prenez d'abord le temps de penser "ce code est-il vraiment si mauvais qu'il ne peut pas vivre à moins de 80 caractères?"

Dans la norme de codage Linux, non seulement ils gardent 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 marge droite, vous devriez envisager de déplacer un niveau d'indentation dans une fonction distincte.

Cela rendra le code plus clair car quelle que soit la longueur d'indentation, il est plus difficile de lire du code avec de nombreuses structures de contrôle imbriquées.

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 trop complexes. Vous ne voulez pas aller trop loin sinon vous encouragez les instructions composées et les structures de contrôle profondément imbriquées.

La bonne marge est la façon dont la nature vous dit d'effectuer une refactorisation de méthode supplémentaire .

Je me demande si cela pourrait causer plus de problèmes à notre époque. 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 des méthodes sont souvent très longs, ce qui rend presque impossible de garder votre code à une longueur de 80 caractères. Je ne pense pas que 80 caractères soient valides aujourd'hui, à moins que vous n'ayez besoin de pouvoir imprimer le code, etc.

En tant qu'auteur des directives de codage pour mon employeur, j'ai augmenté la longueur de la 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 . N'importe quelle imprimante peut également faire des copies papier en mode large avec une police condensée.

La raison de ne pas rester à 80 ans est que je préfère

• préfèrent des noms plus longs avec une signification pour les identifiants
• ne vous embêtez pas avec les typedefs pour les structs et les enums 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 struct FOO func(struct BAR *aWhatever, ...)que du code de 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).

Comme d'autres l'ont dit, je pense que c'est mieux pour (1) imprimer et (2) afficher plusieurs fichiers côte à côte verticalement.

J'aime limiter ma largeur à 100 caractères environ pour autoriser deux éditeurs SxS sur un écran large. Je ne pense pas qu'il y ait de raison valable pour une limite d'exactement 80 caractères.

Utilisez des polices proportionnelles.

Je suis serieux. Je peux généralement obtenir l'équivalence de 100 à 120 caractères dans une ligne sans sacrifier la lisibilité ou l'imprimabilité. En fait, c'est encore plus facile à lire avec une bonne police (par exemple, Verdana) et une bonne coloration de la syntaxe. Cela semble un peu étrange pendant quelques jours, mais on s'y habitue rapidement.

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és / méthodes, les noms de classes, etc. trop détaillés causent autant de tort que les noms laconiques.

Je suis principalement un codeur Python, donc cela produit deux ensembles de limitations:

1. N'écrivez pas de longues lignes de code
2. 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 conserver une seule ligne à moins de 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'assistance ne sont pas une mauvaise chose, ni les classes d'assistance. 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 avoir à appeler une autre fonction et à revenir en arrière. Dans la plupart des cas, le compilateur gérera 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 pouvez avoir une liste de fichiers à gauche et une liste de fonctions à droite (ou toute autre configuration).

Votre code n'est qu'une partie de l'environnement.

Je pense que ne pas appliquer 80 caractères signifie finalement un retour à la ligne.
OMI, 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 offre un retour à la ligne

Mais il est amèrement manqué dans l'éclipse depuis très longtemps ! (depuis 2003 en fait), principalement parce qu'un retour à la ligne pour un éditeur de texte implique:

• Les informations sur la ligne enveloppée concernent la visionneuse de texte, la navigation dans le code et les règles verticales.
• Les informations de ligne non emballées sont requises pour les fonctionnalités telles que la ligne goto, la colonne de la règle de numérotation des lignes, la mise en évidence de la ligne actuelle, l'enregistrement du fichier.

En fait, je suis une règle similaire pour mon propre code, mais uniquement à cause de l'impression du code sur une page A4 - 80 colonnes correspondent à 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 aillent dans l'autre sens).

Que ne remettez-vous pas en question 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 la supprimer 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 un jour. Ceci, bien sûr, est de peu d'intérêt pour les programmeurs en écriture seule appréciant le codage par flèches et les lignes de 300 caractères.

Oui, car même à notre époque, certains d'entre nous codent sur des terminaux (ok, principalement des émulateurs de terminaux), où l'écran 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.

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 assez grands pour afficher encore plus de caractères sur une 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 de ne pas 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é.

Rompre à 80 caractères est quelque chose que vous faites pendant le 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 un de ces , nous ne serions pas cette discussion! ;-)

Mais sérieusement, les problèmes que les gens ont soulevés dans leurs réponses sont tout à fait légitimes. Cependant, l'affiche originale ne contestait pas une limite, simplement que 80 colonnes, c'est trop peu.

La question de l'envoi d'extraits de code par courrier électronique a un certain mérite. Mais compte tenu des mauvaises choses que la plupart des clients de messagerie font au 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 tiennent très confortablement sur une page imprimée.

J'essaie de garder mes lignes en dessous de 80 colonnes. La raison la plus forte est que je me retrouve souvent à utiliser grepet lessà parcourir mon code lorsque je travaille en 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 interrompu 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.