Existe-t-il une raison valable pour imposer une largeur maximale de 80 caractères dans un fichier de code, ce jour et cet âge? [fermé]

https://stackoverflow.com/questions/110928

02-07-2019
|

Question

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

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

La solution

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, mais il existe toujours des raisons valables de conserver la règle des 80 colonnes:

Pour éviter la compression lors de la copie de code dans un courrier électronique, des pages Web et des livres.
Pour afficher plusieurs fenêtres source côte à côte ou à l'aide d'un visualiseur 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 la taille et la résolution des écrans aient augmenté au cours des dernières années, les yeux ne l’ont pas .

Autres conseils

L'origine du formatage du texte sur 80 colonnes est antérieure à celle des terminaux sur 80 colonnes - la carte perforée IBM date de 1928 ! Cela rappelle l’histoire de la (apocryphe) que le gabarit ferroviaire américain a été déterminé par la largeur des roues de 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 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 dans l’intérêt de tous ceux qui n’ont pas d’écran large 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.

En outre, l’œil humain a du mal à lire le texte si les lignes sont trop longues. Il est trop facile de se perdre dans quelle ligne vous êtes. 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.

L'impression d'une police à espacement fixe aux tailles par défaut est (sur du papier A4) de 80 colonnes sur 66 lignes.

Lorsque vous avez une séquence d'instructions qui se répète 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é en 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 procéder comme indiqué ci-dessus:

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 que cela corresponde maintenant à 80 colonnes, je pense que mon argument est toujours valable et que je viens de prendre un mauvais exemple. Cela démontre tout de même que le fait de placer plusieurs déclarations sur une ligne peut améliorer la lisibilité.

J'utilise l'avantage des écrans plus grands pour avoir plusieurs morceaux de code l'un à côté de l'autre.

Vous ne recevrez pas de munitions de ma part. En fait, je n’aimerais pas le voir changer car en cas d’urgence, je vois encore de rares cas où je dois changer le code à partir d’une console de texte.

Les lignes super longues sont plus difficiles à lire. Ce n’est pas parce que vous pouvez avoir 300 caractères sur votre moniteur que vous devez créer des lignes aussi longues. 300 caractères, c'est aussi beaucoup trop complexe pour une instruction, à moins que vous n'ayez pas le choix (un appel qui nécessite tout un tas de paramètres.)

J'utilise en règle générale 80 caractères, mais je vais au-delà si cela impliquerait de placer un saut de ligne dans un emplacement indésirable.

La seule chose que je force à rester dans les 80 caractères est mon commentaire.

Personnellement ... je consacre toute mon énergie cérébrale (le peu qu'il y a) au codage correct, c'est pénible de devoir tout casser à la limite de 80 caractères, alors que je pourrais passer mon temps 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 concernant la disposition de mon code et le modifie ("Ne divisez pas mon code en deux lignes, HAL. HAL? ").

Cela dit, je travaille sur une équipe assez petite et tous nos moniteurs sont assez grands. Il ne faut donc pas s'inquiéter de ce qui dérange mes collègues programmeurs.

Il semble que certaines langues encouragent les lignes de code plus longues pour plus de rentabilité (déclarations abrégées).

J'ai deux 20 " 1600x1200 moniteurs et je m'en tiens à 80 colonnes car cela me permet d'afficher plusieurs fenêtres d'éditeur de texte côte à côte. Utilisation de la police '6x13' (police trad. Xterm), 80 colonnes occupent 480 pixels plus les bordures de la barre de défilement et de la 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 vraiment (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 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 excessivement longs commencent à être contre-productifs car ils rendent difficile la mise en forme cohérente du code. Une bonne mise en page et une bonne indentation fournissent des indices visuels sur la structure du code et certains langages (on pense à Python) utilisent explicitement la mise en retrait 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, de sorte que l'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 autres réponses résument déjà bien les choses, mais il convient également de prendre en compte le moment opportun pour copier & amp; collez du code dans un email, ou si ce n'est pas du code, alors un diff.

C’est le moment d’avoir une "largeur maximale". est utile.

Vous n'êtes pas la seule personne qui va gérer votre code.

La personne suivante peut avoir un 17 " écran ou peut-être 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 cette autre option que "c’est ce qui convient à mon moniteur avec la police Xpt"?

N'oubliez pas qu'il y a toujours des exceptions à chaque règle, de sorte que 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 prenons 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 conservent la limite de 80 caractères, mais ils utilisent également une indentation de 8 espaces.

Une partie du raisonnement est que si vous atteignez la marge de 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 de l'indentation, il est plus difficile de lire du code avec de nombreuses structures de contrôle imbriquées.

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 langues), il existe des règles relatives à la longueur 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 tel que C # ou Java, les noms de 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 sont valides aujourd'hui, à moins que vous n'ayez besoin de pouvoir imprimer le code, etc.

Comme d'autres l'ont déjà 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 à environ 100 caractères pour autoriser deux éditeurs SxS sur un moniteur à écran large. Je ne pense pas qu’il y ait une bonne raison pour une limite d’exactement 80 caractères.

J'ai élargi mon code à 100 caractères, ce qui correspond parfaitement à 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 trop vous écarter, sinon vous encouragez les déclarations composées et les structures de contrôle profondément imbriquées.

La marge de droite est un moyen naturel de vous inviter à effectuer un refactorisation de méthode supplémentaire . .

Utilisez des polices proportionnelles.

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

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Il s’agit de 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 ligne. Être pragmatique à ce sujet et permettre ainsi la "compatibilité ascendante", je dirais que 100 caractères correspondent à la bonne largeur.

En tant qu’auteur des directives de codage pour mon employeur, j’ai porté la longueur de ligne de 80 à 132. Pourquoi cette valeur? Comme d’autres l'ont fait remarquer, 80 correspond à la longueur de nombreux anciens terminaux matériels. Et 132, c'est aussi! C'est la largeur de ligne lorsque les terminaux sont en mode large . Toute imprimante peut également réaliser des copies papier en mode large avec une police condensée.

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

préférez des noms plus longs ayant une signification pour les identificateurs
ne vous embêtez pas avec les types de caractères pour les structures 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), le code a donc plus < code> struct FOO func (struct BAR * aW importe, ...) que le code de fanatiques de typedef.

et sous ces règles, 80 caractères / ligne seulement causent des lignes vilaines plus souvent que mes yeux ne le jugent acceptable (principalement dans les prototypes et les définitions de fonctions).

J'essaie de garder les caractères près de 80 caractères pour une raison simple: trop, cela signifie que mon code devient trop compliqué. Les noms de méthode / propriété trop verbeux, les noms de classe, etc. causent autant de tort que ceux qui sont laconiques.

Je suis principalement un codeur Python, ce qui produit deux ensembles de limitations:

N'écrivez pas de longues lignes de code
Ne pas indenter trop

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 à mémoriser. Si vous ne pouvez pas garder une seule ligne de moins de 80 caractères, votre ligne devient trop compliquée.

En Python, il est facile 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, pas plus que 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 tel que C, écrivez des fonctions d'assistance et insérez-les en ligne si vous ne voulez pas que ce soit une surcharge que d'appeler une autre fonction et de 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 pourriez 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.

Si je n'applique pas 80 caractères, cela signifie finalement que le mot passe à 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 facile que ça en a l'air.

Il est implémenté dans jedit
_{(source: jedit.org )} qui propose un retour automatique aux mots

Mais il est amèrement raté après une longue période ! (depuis 2003 en fait), principalement parce qu’un retour à la ligne pour l'éditeur de texte implique:

Les informations sur les lignes enveloppées sont destinées à la visionneuse de texte, à la navigation par code et aux règles verticales.
Des informations sur les lignes 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 en cours, l'enregistrement du fichier.

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

Qu'est-ce que vous ne remettez pas en question le raisonnement derrière la limite - sérieusement, si personne ne peut trouver une bonne raison pour cela, 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 d’écran de 22 pouces. Je ne sais pas si je le ferai un jour. Ceci, bien sûr, n’a guère d’intérêt pour les programmeurs en écriture seule appréciant les codages en flèche et les lignes à 300 caractères.

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.

Je pense toujours que la limite n'est pas limitée à la partie visuelle. Bien sûr, les écrans et les résolutions sont assez grands pour afficher encore plus de caractères sur une ligne, mais cela améliore-t-il la lisibilité?

Si la limite est réellement appliquée, c'est également une bonne raison de repenser le code et pas de tout mettre en ligne. C'est la même chose avec l'indentation - si vous avez besoin de trop de niveaux, votre code doit être repensé.

Si vous passez à 80 caractères, vous devez coder et non après. Même avec des commentaires, bien sûr. La plupart des éditeurs peuvent vous aider à savoir où se trouve la limite de 80 caractères.

(C’est peut-être un peu OT, mais dans Eclipse, il existe une option qui formate le code lorsque vous l’enregistrez (selon les règles de votre choix). C’est un peu bizarre au début, mais vous commencez à acceptez que le formatage ne soit pas plus entre vos mains que le code généré.)

Si nous avions l'un de ces , nous ne le ferions pas avoir 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 plaidait pas contre une limite, mais plutôt que 80 colonnes, c’est trop peu.

La question de l'envoi par courrier électronique d'extraits de code présente un certain mérite. Mais compte tenu des conséquences néfastes de la plupart des clients de messagerie sur le 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 sont très parfaitement adaptées à 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 grep et moins pour parcourir mon code lorsque je travaille en ligne de commande. Je n'aime vraiment pas la façon dont les terminaux coupent les longues lignes de source (après tout, elles ne sont pas faites pour ce travail). Une autre raison est que je trouve que ça a l'air mieux si tout va bien dans la ligne et n'est pas cassé par l'éditeur. Par exemple, avoir des paramètres d'appels de fonction longs parfaitement alignés les uns en dessous des autres et similaires.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow