Déclarations sur une seule ligne et bonnes pratiques

11

J'ai récemment acquis une habitude que je sais que beaucoup d'entre vous peuvent désapprouver, mais qui, en fin de compte, m'aide à garder un œil sur la structure du code global plutôt que sur la structure d'une seule méthode (parfois) répétitive: regrouper un nombre d'instructions sur une seule ligne, comme ceci:

textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!";

par opposition à

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

J'utilise cela pour des tâches répétitives pour maintenir la «beauté» globale du code et pour m'aider à suivre facilement la structure du programme, mais j'avoue que ce n'est peut-être pas une bonne pratique. En fait, je l'utilise beaucoup, alors j'aimerais savoir ce que vous en pensez. De plus, pensez-vous que quiconque qui aurait à maintenir mon code aurait des problèmes avec cette approche?

coding-style Utilisateur
la source
5
Cela pourrait être une bonne question pour codereview.stackexchange.com
1
J'aurai un problème si je devais continuer. La première chose que je ferais est de faire un CTRL + F pour ";" et mettre un saut de ligne. Mais c'est juste moi :-). Je n'aime une ligne que si j'ai un reasson, par exemple initialiser les propriétés activées de quelques zones de texte avec une valeur par défaut false: textBox1.Enabled = textBox2.Enabled = false;
Arun
2
Si vous posez une question sur le style de codage, il serait utile de spécifier la langue.
Caleb
3
Bien que cela ne puisse pas se produire dans l'exemple donné, comment allez-vous mettre un point d'arrêt sur la deuxième ou la troisième instruction ou ... si vous les mettez tous sur une seule ligne?
Marjan Venema
1
Et aussi, je suis habitué au formatage automatisé (Java), où le code a de toute façon un aspect uniforme.
Kwebble

Réponses:

22

Je pense vraiment que la lisibilité en souffrirait grandement pour vous et certainement pour quiconque lisant le code. Tout cela a du sens lorsque vous l'écrivez la première fois, car il est activement dans votre esprit. C'est différent lorsque vous scannez du code pour voir quelles variables et fonctions se trouvent ... vous détruisez votre propre capacité à scanner votre propre code. C'est un énorme non-non, et au - delà mauvais si quelqu'un d' autre jamais doit lire votre code.

Pensez également à la façon dont vous lisez le code. C'est toujours de haut en bas, de défilement vers le bas. Votre méthode ne correspond pas à cela et introduit même l'un des problèmes les plus laids dans la lecture de code; défilement horizontal . Ne sous-estimez jamais à quel point cela peut rendre la lecture du code difficile. Vous ne faites jamais défiler horizontalement, vous ne faites jamais défiler les gens horizontalement, dans presque tous les contextes, c'est extrêmement contre nature.

De plus, si votre problème est une saisie de code répétitive ... n'oubliez pas Ctrl-C. À partir de votre exemple de code, il pourrait être plus efficace de taper tout cela manuellement, mais si vous devez copier un tas de lignes plusieurs fois, il semble qu'il serait tout aussi efficace de copier la ligne un plus une nouvelle ligne, collez-la x fois et effectuez les modifications, moins susceptibles de faire une faute de frappe aussi.

Oh, et les fautes de frappe! Nuire à la lisibilité de votre code comme cela peut faire du cauchemar la recherche des 50 déclarations de variable que vous avez mal définies. La plupart des compilateurs donnent des erreurs sur les numéros de ligne ET de colonne maintenant, mais trouver une erreur sur une ligne est BEAUCOUP plus facile que de trouver une colonne.

Ben Brocka
la source
2
a) Lecture / lecture de code - La plupart des gens qui lisent le code lisent les premiers caractères de la ligne, puis avancent à moins que ce ne soit "intéressant", puis ils en lisent quelques autres. Erreurs du compilateur: La plupart du temps, j'interprète l'erreur du compilateur comme "Problème avec la ligne <x>". seulement si je peux; t le résoudre instantanément (rare), donc j'ai lu l'erreur.
mattnz
19

Une instruction par ligne permet également de voir plus facilement ce qui a changé dans un diff côte à côte.

Hugo
la source
2
C'est probablement la principale raison, si quelqu'un doit fusionner ce code, presque tous les outils de fusion vont faciliter l'isolement et le déplacement des lignes plutôt que des sous-chaînes de lignes.
Anon
@anon Bon point également sur les outils de fusion; une instruction par ligne signifie moins de conflits de fusion à nettoyer.
Hugo
10

Bien que l'exemple ne le montre pas, il existe un autre problème avec le regroupement de plusieurs instructions sur une seule ligne. Que faire si l'une des cinq déclarations que vous avez sur une seule ligne lève une exception?

Votre trace de pile indiquera "EBlah à la ligne N" ... et maintenant vous n'avez aucune idée de laquelle de ces cinq déclarations a levé l'exception.

(La même chose se produit avec une déclaration excessivement longue de toute sorte.)

Frank Shearar
la source
2
Le même concept s'applique au débogage, où encore une fois la granularité est généralement un numéro de ligne.
David Hammen
2
Oh mon oui, cela peut être un problème. Un «favori» est lorsque vous obtenez un pointeur nul en vrac dans quelque chose comme foo.bar[grill.boo].flip.flap[flop].mickey(minnie).marshmallow(syntaxe Java / C #). Il est toujours préférable de trier ce type de gâchis avec des lignes supplémentaires (et des variables temporaires… et un Brick Of Clue 2D6 pour le développeur d'origine).
Donal Fellows
7

Une instruction par ligne est un style de codage largement utilisé. En conséquence, la plupart des développeurs qui examineront votre code à l'avenir grimaceront probablement lorsqu'ils verront plusieurs instructions par ligne. Lorsque vous avez l'habitude de voir quelque chose dans un sens, il peut être désorientant de le voir d'une autre manière.

Pour cette raison, je le déconseille, sauf dans de rares circonstances.

Igby Largeman
la source
4

J'ai fait cela il y a 25 ans en utilisant des langages interprétés sur de petits micros fonctionnant avec de faibles vitesses d'horloge, où chaque espace ou retour de chariot éliminé augmentait les performances.

Je grimace maintenant à y penser (bien que cela ait été fait pour une bonne raison).

Malheureusement, un tel code est difficile à lire, et donc difficile à maintenir.

vite_maintenant
la source
1
Vous l'écrivez donc correctement, puis vous supprimez les espaces blancs et toute autre préparation pour votre "copie machine". Tout comme la minification de javascript de nos jours.
CaffGeek
1
Ouais - j'ai écrit un programme pour retraiter le code source comme ça aussi - en 1986. Une autre chose que j'espère ne jamais avoir à refaire.
quick_now
1

Syntaxiquement, il n'y a vraiment rien de mal à cela. Cela dépend vraiment du style de codage de votre équipe.

Comme la plupart du code que j'ai vu (y compris le code qui se trouve à l'intérieur des en-têtes c ++ standard) se fait de cette façon, j'irais avec votre première méthode.

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";
CuriousGeorge
la source
0

C'est un style de codage vraiment inhabituel.

Je vous recommande d'utiliser à la place des lignes vides pour délimiter les parties logiques du code.

svick
la source
0

Aller trop loin vers la droite peut créer autant de problèmes que plusieurs lignes.

J'ai dû gérer certaines instructions SQL avec des dizaines de champs. Normalement, je mettrais un par ligne, mais à quelques reprises, j'en ai consolidé 3 ou 4 à la suite. Cela semble être une bonne idée pendant le développement lorsque vous devez faire défiler plusieurs fois de haut en bas.

Je regrette de revenir sur ce code. Avoir des rangées supplémentaires ne semble pas créer beaucoup de problème, donc je le nettoie habituellement.

JeffO
la source
0

De plus, pensez-vous que quiconque qui aurait à maintenir mon code aurait des problèmes avec cette approche?

Après avoir mis ses mains sur sa tête pendant une minute, il utilisera ses fonctionnalités IDE Regex préférées pour séparer automatiquement tout ce code illisible en une seule instruction par ligne.

Un simple coup d'œil à l'exemple que vous avez montré suffit pour comprendre à quel point la deuxième approche est plus lisible.

Il est beaucoup plus facile de suivre le flux vertical des pages, sans avoir à déplacer vos yeux horizontalement pour toujours.

Regardez votre exemple: vous savez immédiatement que le code concerne la Textpropriété de différents textBoxobjets, et ils contiennent des chaînes comme valeurs. Assez simple.

Jose Faeti
la source
0

Je n'utiliserais pas personnellement un tel style. Résumer

Avantages

  • moins de lignes de code à parcourir
  • peut être utilisé pour grouper sémantiquement du code pour exprimer: "beaucoup de trucs d'affectation". MAIS vous pouvez toujours refactoriser un tel bloc dans une fonction s'il vous dérange trop.

Les inconvénients

  • difficile à lire, il est généralement plus facile de lire le code horizontalement (écrémage, pas de mouvement des yeux, ...)
  • diff devient facilement un cauchemar, y compris la fusion
  • plus difficile à changer (copier-coller, commenter, ...)
  • le débogage peut être un problème dans de nombreux IDE car ils fonctionnent sur des lignes au lieu d'expressions individuelles.
Mar
la source
Certains des «inconvénients» peuvent parfois être des avantages. Par exemple, supposons qu'un morceau de code comporte huit opérations consécutives du formulaire if (x > maxX) {x=maxX; peggedAny = true;}. Si chacune de ces opérations s'intègre facilement sur une seule ligne, je préfère avoir huit lignes comme celle-là plutôt que des dizaines de lignes qui divisent les instructions. Si de telles comparaisons étaient utilisées à suffisamment d'endroits, quatre déclarations du formulaire peggedAny |= pegValueMinMax(ref x, minX, maxX);pourraient être mieux, mais quelqu'un qui lirait cela devrait lire pegValueMinMaxpour voir ce qu'il fait.
supercat
De plus, si un petit morceau de ligne change, un "diff" considérera cela comme un changement de la ligne entière. Si la ligne devait se comporter fonctionnellement comme une unité, ce serait une bonne chose. Sinon, si une opération sémantique est divisée en plusieurs lignes, les modifications apportées à certaines lignes peuvent affecter l'opération d'une manière qui ne serait pas apparente.
supercat