La limite de 80 caractères est-elle toujours d'actualité en période d'écrans large? [fermé]


56

sur un écran large, on peut facilement voir plus de 80 caractères à la fois, sans barres de défilement. Même linus torvalds considère que la limite de 80 caractères est obsolète .

oui, la limite de 80 caractères est-elle toujours pertinente en période de moniteurs à écran large?


1
Il y a une très bonne raison de garder les lignes courtes, par exemple Eclipse. Cela vous permet d’ imprimer vos programmes sur une imprimante normale dans une police lisible sans retour à la ligne.

Dans quel contexte? Si vous demandez dans un contexte de programmation spécifique, je voterais pour la réouverture.
Nicole


Le word wrap de Visual Studio est cassé, la plupart des utilisateurs l'ont donc désactivé. Au lieu de cela, ils mettent en ligne les pauses à la main. Cela semble terrible pour quiconque avec une largeur d'écran différente. visualstudio.uservoice.com/forums/121579-visual-studio/…
Colonel Panic

Réponses:


28

Il existe plusieurs raisons de respecter une limite de 80 caractères (ou une limite de 74 caractères est encore mieux; cela permet au code de rester inférieur à 80 colonnes même lorsque des marqueurs diff et des citations d'e-mails sont ajoutés, si vous passez en revue le code listes de diffusion).

Même à l'ère des écrans larges, j'aime avoir plusieurs fenêtres ouvertes côte à côte, montrant différentes parties du code. Par exemple, un navigateur Web et un courrier électronique sont généralement ouverts sur un écran et deux fichiers et un terminal s'ouvrent côte à côte sur un deuxième moniteur. Si vous avez des lignes de plus de 80 colonnes, vous devez vous en occuper avec l’éditeur qui les entoure (ce qui est moche et rend le code plus difficile à naviguer), ou élargissez vos fenêtres de sorte que vous ne puissiez pas en afficher autant à l’écran à une fois que.

Même si vous n'éditez pas de cette façon, si vous utilisez un outil de comparaison côte à côte, vous apprécierez les fichiers dont la longueur de ligne est raisonnable, ce qui facilitera l'affichage de votre différence.

Il y a aussi un problème de densité de code. J'aime avoir beaucoup de contexte lors de la lecture du code. Il est beaucoup plus rapide de regarder d'une fenêtre à l'autre que de faire défiler. Si vous avez de très longues lignes, vous avez également tendance à avoir des lignes qui varient beaucoup en longueur, ce qui entraîne beaucoup de gaspillage d’écran et vous permet d’ajuster moins de code à l’écran à un moment donné.

Enfin, si vous avez de très longues lignes, cela signifie généralement que vous avez des lignes très compliquées, une indendation profonde ou des identificateurs très longs. Tout cela peut poser problème. Les lignes compliquées en font probablement trop; si vous pouvez le décomposer en plusieurs lignes plus simples, vous devriez probablement. Une indentation profonde signifie que vous imbriquez trop de boucles et de conditions, ce qui peut rendre le flux de votre code déroutant. envisager de refactoriser plusieurs fonctions. Et si vos identifiants sont trop longs, la lecture de votre code peut s'avérer très difficile. Les gens reconnaissent généralement les mots comme des unités individuelles; ils ne lisent pas chaque caractère un à un, mais examinent la forme générale du mot. Les identifiants longs sont plus difficiles à distinguer de cette façon et, s'ils sont aussi longs, ils contiennent des informations redondantes ou répétitives.

Maintenant, même s'il est toujours pratique de conserver le code en dessous de 80 colonnes, il ne s'agit pas d'une de ces règles à respecter scrupuleusement, en vous contournant pour adapter une ligne alors que ce n'est pas le cas. Je suggère que vous essayiez de garder tout votre code sous 80 colonnes, mais quand ça ne va pas, ne vous inquiétez pas trop.


3
D'accord. Cependant, les identifiants longs sont parfois encouragés (par des directives de codage telles que "utiliser des noms significatifs" ou "éviter les abréviations cryptiques") ou nécessaires (tels que std::vector<...>::const_iterator), bien que dans ce dernier cas, les choses puissent généralement être allégées par typedefs.
musiphil

Bonnes raisons. Je ne suis pas sûr que la longueur de ligne exacte compte, tant que votre équipe (ou votre liste de diffusion?) L'accepte. Personnellement, j'y vais avec la suggestion de mon oncle Bob de ne jamais dépasser 120 caractères.
Allan

1
@musiphil Ouais, c'est pourquoi j'ai inclus le dernier paragraphe. J'ai rencontré des lignes en C ++ où je ne pouvais tout simplement pas adapter le nom de la classe, le nom de la méthode et le type de retour sur une ligne de 80 colonnes lors de la déclaration de la méthode. Plutôt que de faire des sauts de ligne vraiment étranges, il est préférable de casser simplement la règle des 80 colonnes (ou 100 colonnes) pour cette ligne.
Brian Campbell

46

Si mes lignes ne contiennent pas moins de 100 caractères, je peux avoir deux fenêtres d’éditeur côte à côte sur un moniteur à écran large. Il est très utile d'avoir à la fois le fichier d'en-tête de classe et l'implémentation visibles en même temps, ou d'avoir le code d'un côté qui appelle le code de l'autre. Et, si les lignes sont courtes, je n'ai pas besoin d'une barre de défilement horizontale dans la fenêtre de l'éditeur, ce qui me donne plus d'espace vertical.

80 caractères peuvent être obsolètes, mais il y a un intérêt à garder les choses dans les limites de la raison.


1
+1, j'ouvre fréquemment plusieurs fichiers sources côte à côte dans Vim ou d'autres éditeurs. Avec une police suffisamment petite et une marge droite assez étroite, je peux très rapidement avoir une bonne vue d'ensemble du projet et même ouvrir beaucoup de documentation.
Greyfade

4
80 caractères sont toujours d'actualité, car beaucoup de personnes n'utilisent généralement que leurs terminaux et leurs éditeurs. ainsi, si vous vous limitez à 80, vous serez amical envers ces personnes, au lieu de leur demander de réorganiser toutes leurs fenêtres ou de traiter le retour à la ligne ou le défilement horizontal.
Brian Campbell

1
80 caractères est toujours raisonnable; aller plus longtemps que cela encourage le code sur-imbriqué (au lieu de refactoriser!) et avoir plusieurs fenêtres côte à côte est extrêmement utile. Ajouter un autre moniteur augmente simplement le nombre de fenêtres que vous pouvez voir en même temps!
Donal Fellows

1
80 est sympathique à VMS peut-être. Pardonnez à mon nouvel âge de penser, mais nous devrions prolonger la limite si possible et la garder si nécessaire ..
Ross

29

Je ne pense pas que le moniteur ait quelque chose à voir avec cela - du moins plus maintenant.

Si vous ne pouvez pas coder une ligne de 80 caractères, c'est probablement un signe de mauvais code. Des expressions trop complexes. Indentation trop profonde. etc. Vous devriez arrêter et repenser ce que vous faites.

Mais si vous êtes certain que le code nécessite plus de 80 lignes, continuez et faites-le. Je pense qu'il est préférable d'avoir un code dépassant les 80 caractères plutôt que d'ajouter des modifications idiomatiques uniquement pour le rendre plus petit.

Personnellement, je déteste ce genre de choses:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

Au lieu de simplement:

ret = my_function(parameter1, parameter2, parameter3, parameter4);

5
Si la ligne 3 du premier exemple n’est pas trop longue, la ligne 2 peut être combinée à la ligne 1, ce qui la rend beaucoup plus lisible. (Quelle langue nécessite des nouvelles lignes échappées entre parenthèses?)

1
Ahh, c'est juste un pseudo-code que j'ai écrit. Mais je pense que C en a besoin.
Cesar Canassa

4
Uniquement dans les définitions de macros multilignes, qui sont (ou devraient être) rares. Cela affecte considérablement le choix de la longueur de ligne maximale (le maintien de telles barres obliques inverses n'est pas amusant), alors je suis curieux de savoir pourquoi vous le montrez. Semble être un homme de paille ?

2
Si je me donnais la peine de couper une ligne dans un appel de fonction, je mettrais chaque paramètre sur sa propre ligne, en retrait d'un niveau.
starblue

20

Pour coder?

Oui, certainement. Un être humain normal ne sait pas lire trop large. Avec quelques colonnes, vous bougez moins les yeux, vous vous concentrez mieux et vous retardez la fatigue. C'est un gain minimum, mais important.


3
Bien que je pense que le code est très différent de la prose, il est fatiguant de lire du code qui (périodiquement, la prose serait généralement beaucoup plus cohérente) étend les lignes à plus de 120 colonnes.

6

Oui, il y a des raisons de limiter la longueur de la ligne de code:

  1. Bien que nos écrans soient de plus en plus larges, vous devez parfois imprimer votre code. Si seulement pour cette raison .
  2. Les visualiseurs de différences affichent souvent des lignes divisées verticalement - cela devient plus difficile si les lignes sont aussi longues que le permettrait un écran large.

Cela dit, 80, c'est un peu trop. Néanmoins, certaines limitations constituent probablement une bonne idée en tant que principe de conception.

Je dirais que les lignes très longues ne devraient pas être interdites, car elles sont parfois nécessaires. Mais si la plupart des fonctions ne sont visibles que sur un écran de 30 ", le code pose quelques problèmes.


5

C'est arbitraire, mais il y a une limite non arbitraire à ce qui est facile à lire. Je trouve que les colonnes de texte très larges sont très difficiles à numériser et à lire, qu’il s’agisse de code ou de prose. De plus, comme de nombreuses autres réponses l'ont souligné, ce n'est pas comme si ce code allait être la seule chose à l'écran. Il est bon d'avoir deux fenêtres de code ou plus en même temps et de les placer sur un seul écran large.


3

Il n’est probablement pas pertinent de choisir exactement 80 caractères; Qu'est-ce qui changerait si la limite était de 85, par exemple?

Il est vrai que les moniteurs utilisés aujourd'hui ont des résolutions plus élevées, mais dans un éditeur de texte / IDE, tout l'espace n'est pas pris dans la vue texte; Dans l'éditeur que j'utilise, on voit à gauche la liste des fichiers inclus dans le projet.

La résolution utilisée dans un netbook ou un ordinateur portable n’est pas la même que celle utilisée dans les moniteurs; il est probablement logique d'utiliser une limite de caractères qui ne crée pas de "problèmes" pour personne.


5
80 caractères était la limite stricte du nombre de colonnes sur la carte perforée!
ChrisF

5
Peu importe la norme, mais si tout le monde respecte la même norme, cela facilite la vie.
Skilldrick

2

Cela dépend vraiment de l'environnement de développement.

Par exemple, dans une grande entreprise comptant des milliers de développeurs, des centaines de personnes devront probablement, au cours de la durée de vie d'un produit, consulter une partie de son code. Avec autant de gens, il y en a forcément quelques-uns qui, pour une raison quelconque (vieux matériel, netbooks, etc.) fonctionnent à 800x600 ou moins. Il y a une certaine valeur à les accueillir.

Dans mon entreprise de 25 personnes, cependant, je dis que je le vis. Nous utilisons tous deux moniteurs modernes à la résolution maximale, soit 120-140 environ.


2

Avoir une limite a du sens. Mais la limite de 80 caractères est trop contraignante. Je préfère quelque chose comme 96 caractères maximum. Il est suffisamment large pour la plupart des codes que je dois traiter et suffisamment étroit pour que deux fichiers puissent être mis côte à côte pour être différés (sur un écran large).

Je crois que la lisibilité du code l'emporte sur toutes les autres préoccupations. Et avec 96 caractères par ligne, le code peut être rendu beaucoup plus lisible qu'avec 80.

Je n'accepte pas l'argument voulant que la plupart des utilisateurs définissent leurs terminaux sur 80 caractères au maximum, mais non que les imprimantes doivent insérer des lignes de plus de 80 caractères. Ce n'est pas une limite difficile, comme c'était le cas dans le passé (lointain). Vous pouvez facilement définir le terminal et la largeur de l’imprimante sur 100 caractères.


1

Non, ce n'est plus pertinent:

  • La plupart des polices utilisées dans les applications et sur le Web n’ont de toute façon pas une largeur fixe. En d'autres termes, 80 caractères! = 80 caractères.
  • Comme vous l'avez dit, la largeur de l'écran a changé: 80 caractères ne constituent pas une limite raisonnable.

80 caractères était vraiment un guide pour les polices à largeur fixe dans un environnement de console.

Bien sûr, si vous utilisez toujours une police à largeur fixe dans un environnement de console ... alors, 80 caractères, c'est raisonnable :)


3
Je suis presque sûr qu'il parlait de l'utilisation d'une limite de 80 caractères dans le code source, qui est presque universellement affichée dans des polices à espacement fixe.
Fishtoaster

1
Hmm ... dans ce cas ... toujours non, mais pour d'autres raisons :)
Damovisa le

1
80 caractères était la limite stricte du nombre de colonnes sur la carte perforée!
ChrisF

0

Si vous utilisez un éditeur dans une interface utilisateur graphique, les 80 caractères par ligne ne sont pas pertinents, car la plupart des éditeurs décents - par exemple Notepad ++ - ont un bouton pour basculer le retour à la ligne. Avec cela, cela ne devrait pas être un problème, même lors de la visualisation du code dans une fenêtre mince.

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.