Limitez-vous toujours la longueur des lignes dans le code ?

Question

Il s'agit d'une question sur laquelle j'aimerais connaître l'opinion de la communauté : Limitez-vous toujours la longueur des lignes de code à un maximum fixe ?

C'était certainement une convention du passé pour de nombreuses langues ; on limitait généralement le nombre de caractères par ligne à une valeur telle que 80 (et plus récemment 100 ou 120 je crois). D'après ce que je comprends, les principales raisons de limiter la longueur des lignes sont les suivantes :

• Lisibilité - Vous ne devez pas faire défiler l'écran horizontalement lorsque vous voulez voir la fin de certaines lignes.
• Impression - Certes (du moins d'après mon expérience), la plupart des codes sur lesquels vous travaillez ne sont pas imprimés sur papier, mais en limitant le nombre de caractères, vous pouvez vous assurer que le formatage ne sera pas perturbé lors de l'impression.
• Anciens rédacteurs ( ?) - Je ne suis pas sûr de cela, mais je soupçonne qu'à un moment donné dans le passé lointain de la programmation, (au moins certains) éditeurs de texte ont pu être basés sur un tampon à largeur fixe.

Je suis sûr qu'il y a des points que j'oublie encore, alors n'hésitez pas à les compléter...

Aujourd'hui, lorsque j'observe du code C ou C#, je vois souvent un certain nombre de styles différents, les principaux étant :

• Longueur de ligne plafonnée à 80, 100, voire 120 caractères. D'après ce que j'ai compris, 80 est la longueur traditionnelle, mais les longueurs de 100 et 120 sont apparues en raison de l'utilisation répandue des hautes résolutions et des écrans larges de nos jours.
• Aucun plafonnement de la longueur de la ligne. Ça a tendance à être assez horrible à lire, et je ne le vois pas trop souvent, mais ce n'est certainement pas trop rare non plus.
• Le plafonnement de la longueur des lignes n'est pas cohérent. La longueur de certaines lignes est limitée à un maximum fixe (ou même un maximum qui change en fonction du fichier/emplacement dans le code), tandis que d'autres (éventuellement des commentaires) ne le sont pas du tout.

Ma préférence personnelle (du moins récemment) a été de limiter la longueur des lignes à 100 dans l'éditeur Visual Studio. Cela signifie que dans une fenêtre de taille raisonnable (sur un écran non large), les extrémités des lignes sont toujours entièrement visibles. Je peux cependant y voir quelques inconvénients, notamment lorsque vous finissez par écrire du code indenté sur 3 ou 4 niveaux et que vous devez ensuite inclure une longue chaîne littérale - bien que je prenne souvent cela comme un signe pour remanier mon code !

En particulier, je suis curieux de savoir ce que les codeurs C et C# (ou quiconque utilise Visual Studio, d'ailleurs) pensent de ce point, mais je serais intéressé d'entendre les réflexions de quiconque sur le sujet.

Editar

Merci pour toutes les réponses - j'apprécie la variété des opinions ici, toutes présentant des raisons valables. Le consensus semble pencher en faveur de toujours (ou de toujours presque toujours) limiter la longueur de la ligne.

Il est intéressant de noter que la limitation de la longueur des lignes semble faire partie de plusieurs normes de codage. À en juger par certaines des réponses, les directives Python et Google CPP fixent la limite à 80 caractères. Je n'ai rien vu de similaire concernant C# ou VB.NET, mais je serais curieux de voir s'il en existe quelque part.

Answer 1

Je limite toujours les lignes à 80 caractères :

• De cette façon, je peux visualiser trois fichiers en même temps, chacun dans une colonne côte à côte. (Cela s'avère particulièrement utile lors d'une fusion à trois).
• Je suis sûr que le code sera lisible lorsque je l'imprimerai ou le mettrai sur une page web.
• C'est le standard limite pour le code Python.

Answer 2

Normalement, je ne m'inquiète pas trop à ce sujet, surtout pas au point de fixer une limite fixe. En général, je me fie à la lisibilité réelle dans mon esprit. Si j'ai du mal à tout lire sur une seule ligne, je la divise. Il y a quelques cas où je le fais (presque) invariablement : les méthodes avec plusieurs paramètres, notamment lors de l'utilisation de la technique du constructeur automatique en C#, et les invocations de méthodes enchaînées, comme lors de l'utilisation des extensions IEnumerable. Je le fais même lorsque la longueur de la ligne n'est pas vraiment un problème. Typiquement, dans ce dernier cas, je diviserai les méthodes sur la ligne dot et mettez chaque méthode sur une ligne séparée.

 var query = table.Where( s => s.something ).Select( t => t.property ).FirstOrDefault()

devient

 var query = table.Where( s => s.something )
                  .Select( t => t.property )
                  .FirstOrDefault()

De plus, dans les cas où une fenêtre extrêmement étroite doit être utilisée, comme lors de la fusion, les enveloppes souples peuvent très bien gérer ces cas de nos jours.

Answer 3

J'essaie de m'en tenir à une largeur de 80, et je tente de limiter mes fonctions imbriquées au sein d'une même commande.

Il n'y a rien de plus irritant que de suivre une trace de pile pour trouver la source de l'exception La ligne 23 est une exception, qui se lit comme suit :

23: Object myObj = ob1.kenobi().speak().scratchMyAss().getLightSaber().jediMindTrick();

Super, maintenant quel appel de méthode à la ligne 23 a déclenché l'exception ?

Answer 4

Une chose que personne n'a mentionnée est le courrier électronique. Si vous envoyez des extraits de code par e-mail ou les afficher dans un newsgroup c'est bien si vous pouvez empêcher l'enroulement de la ligne. Si les lignes de votre code sont déjà inférieures à 80 caractères, vous n'avez pas besoin de les reformater.

Autre chose : quelle que soit votre convention, respectez-la. Rien n'est pire qu'un code inutilement reformaté, car cela fait du diffing un cauchemar.

Answer 5

J'essaie certes de limiter la longueur de la ligne (120 actuellement), mais juste pour la lisibilité. J'utilise même une astuce pour me forcer à le faire dans Visual Studio :

http://blog.feradz.com/index.php/2009/02/17/add-line-length-marker-in-visual-studio/

Quant aux niveaux profonds d'imbrication : Je me souviens avoir lu des directives de codage pour écrire du code pour le noyau Linux, je crois qu'elles ont été créées par Linus lui-même. Les directives incluaient le niveau maximum d'imbrication dans une fonction (3 si je me souviens bien) avec le commentaire suivant : si vous avez besoin de plus de 3 niveaux, vous ne devriez pas écrire de code pour le noyau ;)