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


159

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.


Toutes les réponses indiquent à peu près ce que je voulais ajouter. Pour vous donner un exemple réel - j'ai un x61s, la résolution est de 1024x768. Quand je suis sur la route, je n'ai pas mon moniteur sophistiqué. Ouvrir du code dans mon IDE est pénible lorsqu'il dépasse cette règle.
Jusqu'au


Même si vous avez un ensemble de 3 moniteurs. Ce n'est pas une raison pour secouer la tête de droite à gauche et en arrière. Pour toujours. Ah-ha-ha. En fait, l'œil bouge plus vite que la tête. Connaissez-vous les colonnes dans les journaux? La raison de la largeur est la commodité œil / tête / homme.
Ivan Black

Réponses:


258

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 .


7
Ils peuvent avoir «largement disparu», mais pas entièrement. J'ai tendance à travailler avec deux configurations différentes: 1) dans une fenêtre ssh connectée à une machine distante. qui fait 80 caractères de large par défaut. et 2) dans Visual Studio, avec deux panneaux côte à côte pour que je puisse voir l'en-tête et le fichier cpp en même temps.
Enno

10
@steffenj: En fait, les livres ont tendance à tirer pour environ 66 caractères par ligne (bien que cela varie quelque peu en fonction d'autres paramètres) parce que les lignes plus longues font rendent la lecture plus difficile. La longueur maximale de la ligne de code peut être argumentée, mais 80 est pratique pour des raisons historiques et pratiques.
Steve S

70
Le problème est qu'en forçant les gens à réduire la longueur des lignes, ils ont tendance à utiliser des noms moins significatifs.
Ian Ringrose

4
Je trouve les remarques sur la lisibilité assez intéressantes, parce que ce que je déteste vraiment à propos des articles / livres / ... de programmation imprimés, c'est que les lignes courtes qui sont utilisées pour les exemples de code sont extrêmement difficiles à lire. Cela peut avoir beaucoup de sens de déplacer quelque chose vers une nouvelle ligne, mais le regroupement doit se produire de manière logique, disséquant l'expression de manière récursive, pas parce que le périphérique de sortie a accidentellement atteint sa limite. IOW, je trouve que les appareils qui imposent des restrictions aussi étroites ne sont pas bien adaptés pour afficher du code.
Chris Lercher

4
Je pense que le problème avec les exécuteurs à 80 colonnes est qu'ils oublient que le code se développe à la place dans le sens vertical. Vous obtenez le même problème, mais dans la direction verticale ET du haut de ce code moderne, cela semble horrible lorsque vous devez casser des instructions uniques sur deux ou parfois jusqu'à quatre ou cinq lignes. Ce n'est PAS plus lisible. Avec le code moderne, je veux dire les noms de variables descriptives et l'héritage de qualification, les espaces de noms, les classes, etc. 120 est mieux, mais ne devrait pas non plus être une règle.
Larswad

79

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:

Carte perforée FORTRAN


59

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.


1
La limite de caractères ne vous dit pas O vous devez diviser une ligne de code, mais QUAND
gztomas

Non, ce n'est pas le cas. Si vous écrivez une ligne de plus de 80 caractères, vous avez probablement déjà un problème de complexité d'expression ou de stratégie de dénomination. Comme d'autres l'ont mentionné, la lisibilité est une préoccupation majeure et la vitesse de lecture commence à chuter au-dessus de 60 à 66 caractères (typographie, basée sur la physiologie humaine).
sola

@sola Votre commentaire apparaît ici avec 98 caractères, et c'est une langue naturelle non native dense (pour moi) à comprendre. Entièrement lisible. Un code avec jusqu'à 3-4 retraits, marqueurs de syntaxe, etc. est encore plus facile.
viyps le

J'ai accidentellement refusé cette réponse et je ne peux plus la voter. :(
Andy

35

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.


14
Pas lorsque vous ajoutez un retrait dans le mix. Si vous utilisez 4 espaces par retrait, et que vous êtes dans quelque chose comme, namespace-> class-> method-> if-> for, c'est 1 / 5ème de votre espace soufflé.
TraumaPony

Vous pouvez toujours définir la règle à 80 caractères à partir du retrait. De cette façon, l'œil peut facilement le suivre.
Vincent McNabb

Parfois, (mais pas toujours) je souhaite que .Net ait un espace de noms automatique pour que vous n'ayez pas à définir l'espace de noms dans le fichier. Cela perturbe gravement l'alignement de votre code. si vous voulez des espaces de noms imbriqués, vous avez de très gros problèmes.
Kibbee

13
Cependant, lire de la prose n'est pas la même chose que lire du code.
Atario

3
+1 pour les journaux, excellent exemple. @Antario, lire du BON code ressemble beaucoup à la lecture de la prose.
Todd Chaffee

23

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é.


8
En disant qu'il n'y a que de petites différences d'une ligne à l'autre, vous dites également qu'il y a beaucoup de code redondant. Supprimer une partie de cela pourrait réduire considérablement le nombre de colonnes tout en restant aligné verticalement.
foraidt

@mxp: d'accord. S'il y a une manière plus concise d'écrire ce qui précède, je serais intéressé de le voir.
Sam Hasler

Je suis d'accord avec l'idée générale, mais l'exemple ... Qu'en est-il de ceci: switch (...) {case ... BL: dxDir = - 1; dyDir = -1; Pause; cas ... BR: dxDir = + 1; dyDir = -1; Pause; ...} ... ["X"] = pt1.x + dxDir * Rad ... X; ... ["Y"] = pt1.y + dyDir * Rad ... Y;
Yarik

38
Le fait que je doive faire défiler le premier des deux exemples horizontalement prouve en quelque sorte que les lignes plus courtes sont meilleures :-)
Enno

1
Je ne comprends pas la haine du défilement? C'est une opinion commune, et je ne dis pas que c'est faux, je ne comprends tout simplement pas. Surtout si vous êtes dans un éditeur de code, vous n'avez même pas besoin de déplacer vos mains du clavier pour accéder à la souris - juste (ctrl+)arrowau - dessus ou appuyez surend
KOGI

21

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


16

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.


14

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.


Il existe des études qui montrent que les gens peuvent lire et suivre un nombre x de caractères / mots avant de perdre la trace. Je pense que 80 est là quelque part. Cependant, je n'ai aucune source pour étayer cela.
Jusqu'au

Ouais, je pense que vraiment, il ne s'agit pas de garder les lignes courtes mais plutôt de garder les lignes propres / concises / lisibles / compréhensibles.
KOGI

Si vous avez un (un appel qui a besoin de tout un tas de paramètres.), Vous devez quand même refactoriser.
Zarremgregarrok

@Zarremgregarrok J'ai vu de très longues listes de paramètres dans les API Microsoft.
Loren Pechtel

@LorenPechtel Est-ce que cela le rend bien écrit?
Zarremgregarrok

8

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).


7

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 .


Merci d'avoir dit ça! Les grands moniteurs sont une raison de plus pour la limite de 80 lignes, vous pouvez donc installer plus de fenêtres côte à côte. Sans compter que c'est bien de pouvoir parfois imprimer le code source (sur papier). Ou collez des extraits dans d'autres documents.
dreeves le

7

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.


5
Je ne suis pas fan des barres de défilement horizontales
bryc

9
Je suis surpris que personne n'ait dit cela, étant donné que j'ai plusieurs années de retard dans cette discussion, mais je pense que les nouvelles lignes (peut-être avec un retrait pour plus de clarté) juste avant les mots-clés «étend» et / ou «implémente» produiraient encore des code lisible.
mtraceur

2
J'adore le fait qu'il dit "il est très lisible sur une seule ligne" alors qu'en même temps je ne peux pas lire l'extrait de code en entier car il déborde de l'espace horizontal dans le navigateur. Point réfuté.
oligofren

6

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.


6

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?"


1
Je vivrai avec 80 caractères quand je pourrai avoir des tabstops 2spc. Mieux encore, utilisez réellement des tabulations pour l'indentation, l'exigence est lorsque tabsize = 2, tient dans 80 colonnes, utilisez 4 la plupart du temps pour une meilleure lisibilité. De cette façon, lorsque vous devez vraiment étouffer jusqu'à 80 colonnes, vous pouvez, mais à un prix.
Joshua

5

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.


3
Que diriez-vous de lire du code avec de nombreux appels de fonction? Il y a sûrement un compromis entre ces deux approches ...
Zsolt Török

5

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 .


5

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.


5

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).


4

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.


4

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.


4

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.


Vraiment mauvaise idée lorsque vous souhaitez utiliser des «retraits» et des polices à espacement fixe.
Bersaelor

2
@Bersaelor Non, cela fonctionne très bien lorsque vous indentez toujours en utilisant uniquement des tabulations et que vous définissez correctement la largeur de l'onglet (la largeur 4 monospace est peut-être 7 proportionnelle). L'indentation fonctionne, vous ne pouvez tout simplement pas faire de l'art ASCII, mais je ne pense pas que l'art ASCII appartient au code.
maaartinus

Personnellement, je suis plutôt du côté opposé lors de la programmation. Je trouve le code proportionnel très difficile à lire. Parfois, je configure même l'EDI pour utiliser des polices monospace (oui, y compris les menus).
Sebastian Mach

2

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.


2

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.


2

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 lignetexte alternatif

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.

1

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 suis presque sûr que cela date de l'époque où les écrans en mode texte avaient 80 caractères de large.
TraumaPony

1

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.


1

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.


0

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é.


0

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é.)


0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.