Dans quelle mesure est-il important de réduire le nombre de lignes dans le code?
Je suis un développeur de logiciels qui travaille sur J2SE (noyau Java).
Souvent, lors de nos révisions de code, il nous est demandé de réduire le nombre de lignes dans notre code.
Il ne s'agit pas de supprimer du code redondant, il s'agit de suivre un style qui se concentre sur la même chose avec moins de lignes dans le code, alors que je crois en la clarté du code même si cela signifie augmenter le nombre de lignes.
Selon vous, quelle est la bonne façon de faire les choses?
Si LOC (lignes de code) est un petit nombre, comment cela affecte-t-il le code? Si LOC est un plus grand nombre, comment cela affecte-t-il le code?
exemple du site: "javaranch" -
public static void happyBirthday(int age)
{
if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))
{
System.out.println("Super special party, this year!");
}
else
{
System.out.println("One year older. Again.");
}
}
CONTRE
public static void happyBirthday(int age)
{
boolean sweet_sixteen = (age == 16);
boolean majority = (age == 21);
boolean adult = (age > 21);
boolean decade = (age % 10) == 0;
boolean quarter = (age % 25) == 0;
if (sweet_sixteen || majority || (adult && (decade || quarter)))
{
System.out.println("Super special party, this year!");
}
else
{
System.out.println("One year older. Again.");
}
}
Le problème des mesures, quelle que soit leur intention, est que l'acte même de mesurer l'élément le rend important et le corollaire, le fait de ne pas mesurer un élément, le rend sans importance. Il est absolument essentiel de mesurer ce qui est important et non de mesurer ce qui est sans importance.
La mesure du SLOC (qui est effectivement ce que font vos avis), rend le SLOC important .... Le SLOC est-il important? - absolument pas, n'a jamais été (Outside Concours de programmation obscurcis ), ne sera jamais dans une organisation commerciale.
Posez-vous une question simple - comment "réduire le SLOC de cette routine" améliore-t-il le code de quiconque. Ce qui se passe probablement dans ce cas, c'est que le SLOC est utilisé comme un moyen naïf pour mesurer la complexité. Ce que vous devez éviter à tout prix est de compter les grains faciles à compter - des mesures objectives telles que le SLOC, au lieu de compter les importantes, mais difficiles à compter - par exemple Lisibilité, complexité, etc.
Je suis d'accord avec vos réviseurs de code, mais avec un astérisque. Chaque déclaration que vous écrivez dans votre code est une responsabilité technique - c'est un point d'échec potentiel. Si vous écrivez une méthode avec 10 instructions et que votre collègue en écrit une qui atteint la même fonctionnalité avec 5 instructions, la sienne sera probablement `` meilleure '', mesurée par la probabilité de problèmes (il y a deux fois plus d'endroits où votre code peut être erroné, trop complexe ou problématique).
Voici l'astérisque, cependant. Il ne s'agit pas du nombre réel de lignes de code dans l'idée car vous pouvez réduire le nombre de lignes avec quelque chose comme:
void someMethod() {
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}
Il s'agit d'une seule ligne de code, mais c'est un endroit où une quantité incroyable de choses peuvent mal tourner. Je dirais donc que vous devez vous concentrer sur le maximum avec le moins d'instructions - écrivez autant de code que nécessaire pour faire avancer les choses et pas plus. Du moins, je pense que c'est ce vers quoi vos réviseurs de code cherchent.
Personnellement, je pense qu'il y a un équilibre à trouver. Comme je l'ai dit, chaque déclaration que vous écrivez est un handicap, mais si extraire une variable locale avec un nom descriptif rend votre méthode beaucoup plus claire et plus lisible, alors il y a un argument à faire aussi. Je pense que vous pouvez facilement vous retrouver dans des situations où les gens chicanent sur des différences esthétiques relativement mineures, mais dans l'ensemble, je pense que vos critiques ont la bonne idée - préférez minimiser le nombre de choses qui peuvent mal tourner.
Prendre littéralement les conseils des examinateurs ne servira à rien, car le résultat direct évident est la promotion de lignes uniformes laconiques (malgré la limite de longueur de ligne). Je crois cependant que la leçon à tirer ici est de faire faire moins de choses à votre code.
En d'autres termes, c'est un appel à la simplicité. Il est assez populaire d'affirmer que le code est un passif, pas un actif , donc réduire son montant tout en préservant la fonctionnalité est un noble effort. Cela peut être réalisé par une approche directe, plus terre à terre, qui traite directement le problème et préfère des solutions concises.
Comme Ken Thompson l'a dit un jour: L'un de mes jours les plus productifs a été de jeter 1000 lignes de code .
J'ai tendance à être d'accord avec votre position "d'avoir de la clarté dans le code même si cela signifie augmenter le nombre de lignes".
J'ai vu trop de one-liners qui sont assez laconiques, mais on ne voit pas immédiatement ce qu'ils font. La lisibilité est reine car les autres développeurs devront maintenir votre code.
Je dirais qu'une meilleure chose à viser est des méthodes courtes. Pas court pour quelques lignes de code, mais court parce qu'ils font une seule chose.
Je travaille actuellement en tant que développeur d'applications senior et analyste d'affaires de projet pour une grande entreprise et le nombre de lignes de mon développement n'a jamais été un centre d'intérêt. Cependant, je pense que plus un code peut être condensé, mieux c'est, MAIS pas au prix de pouvoir rapidement l'analyser et le corriger (ou y ajouter). Pour moi, lorsque vous êtes en charge d'une application critique pour l'entreprise qui DOIT avoir un vaste niveau d'évolutivité et capable de modifications à la volée dans un environnement en constante évolution, un code concis et facile à lire est l'un des éléments les plus importants du développement . Au crédit de réponse d'Erik Dietrich , ceci:
void someMethod() {
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}
serait tout à fait inacceptable pour moi, cependant, j'ai trouvé la modification du code existant de toutes les sociétés de:
if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}
à:
value.prop = boolean ? option1 : option2;
était un excellent choix de condensation de code qui ne sacrifie pas la lisibilité.
En ce qui concerne la façon dont cela affecte le code? Je n'ai jamais remarqué d'augmentation ou de diminution des performances de, disons, 100 lignes de code. Le simple fait est que c'est plus le processus que vous utilisez pour arriver au produit final que le nombre de lignes qu'il faut pour y arriver. J'ai vu certains processus écrits très condensés, mais inefficaces, fonctionner différemment des codes plus longs avec un meilleur flux de code.
OMI, c'est une mauvaise idée de mesurer l'efficacité du code par un nombre LOC insignifiant. Il y a beaucoup plus sur ce qui rend un code correctement conçu et efficace.
D'après mon expérience, un code efficace:
- ne casse aucun des principes SOLIDES
- est lisible et explicite
- passe le test de simplicité d'Albert Einstein: "Tout doit être aussi simple que possible, mais pas plus simple."
Il y a beaucoup de réponses ici qui traitent des avantages et des inconvénients techniques de garder LOC bas et s'il s'agit ou non d'une métrique logicielle de qualité significative. Ce n'est pas de cela qu'il s'agit. Il s'agit de savoir comment traiter avec la direction qui insiste sur une adhésion dogmatique naïve à une règle empirique de codage particulière.
Malheureusement, il est assez courant que les gens s'accrochent à des choses qui sont de bons conseils lorsqu'ils sont utilisés dans le bon contexte et appliqués de manière pragmatique, les retirent de ce contexte et les appliquent de manière dogmatique tout en ne comprenant pas les problèmes que les conseils existent pour atténuer en premier lieu .
Le but des conseils concernant le maintien de LOC est d'éviter la création de méthodes qui essaient d'en faire trop en une seule fois, et de décourager la création de "classes divines", qui en savent trop sur les aspects d'une conception qui ne sont pas leurs responsabilité directe et dont dépendent toutes les autres classes du système. Un autre avantage du code plus court est qu'il est plus lisible, mais comme vous l'avez souligné, vous pouvez en faire trop au point où la lisibilité commence à en souffrir.
Il y a des avantages évidents à un faible nombre de LOC (les petites méthodes s'insèrent plus facilement dans la tête que les grandes, moins de choses dans le code signifient moins de choses qui tournent mal, etc.), mais il est également soumis à la loi des rendements décroissants. La refactorisation d'une méthode de 150 lignes en un certain nombre de méthodes de 20 lignes est un gain beaucoup plus important que la refactorisation d'une méthode de 10 lignes en une méthode de 7 lignes.
Quand une telle refactorisation se fait au détriment d'une autre facette d'une bonne conception logicielle (comme la lisibilité), alors vous avez atteint un point où vous pouvez justifier de ne pas le faire. Supprimer des variables qui donnent un contexte à ce que signifie le code et les remplacer par des littéraux qui ne le sont pas est une très mauvaise chose à faire. Un bon code ne contient presque pas de littéraux. Cependant, ces variables (et les constantes nommées) sont des lignes de code qui ne contribuent pas directement au programme et donc si LOC est adoré comme une sorte de dieu, ces lignes de clarification sont en grand danger d'être élaguées pour une victoire rapide et certains éloges erronés de la direction.
Je pense que vous êtes assez intelligent pour réaliser cela, en fait c'est à peu près le sens de votre question initiale. Le problème n'est pas que vous compreniez quand la réduction de code est bonne et quand elle ne l'est pas, le problème est le dogmatisme dans l'application aveugle de ce qui est normalement une pratique raisonnable.
Je recommanderais de prendre le temps de discuter avec votre direction, d'expliquer votre position et pourquoi vous pensez que ce qu'on vous demande de faire nuit au code plutôt que de l'aider. Essayez d'éviter d'être conflictuel, mais essayez de rester rationnel et calme pendant une telle discussion. Il est important que votre direction comprenne que la programmation est une activité pragmatique et que les conseils de bonnes pratiques ne sont utiles que s'ils sont appliqués de manière pragmatique. Les meilleures pratiques sont écrites dans un livre, non gravées dans la pierre, et en cas de conflit (code court ou code lisible), il appartient au programmeur d'appliquer son jugement quant à la meilleure pratique à suivre. J'espère que ce sont des gens raisonnables qui apprécient les commentaires comme celui-ci.
Vous devez également être un peu courageux, car si vous êtes contraint de réduire le LOC là où vous pensez que c'est inutile ou inapproprié, il est naturel que vous fassiez le changement de toute façon pour une vie tranquille. Vous devez résister à faire cela, et vous devez "posséder" cette décision. Dans une situation où la direction est raisonnable, vous ne devriez pas avoir à respecter exactement leurs directives, mais vous devriez pouvoir justifier toutes les circonstances où vous ne le faites pas.
Malheureusement, les gens peuvent être irrationnels, surtout quand il s'agit de personnes de rang hiérarchique remettant en question leurs décisions et les règles qu'ils vous ont imposées. Ils peuvent choisir de ne pas être raisonnables. Vous devez également vous y préparer. Si vous pouvez démontrer des cas où les meilleures pratiques LOC entrent en conflit direct avec d'autres bonnes pratiques et pourquoi cela nuit au produit, et si vous pouvez le faire dans des parties de la base de code pour lesquelles ils n'ont eu que peu ou pas d'implication personnelle (il n'en est rien ne semblent pas être une attaque personnelle contre leur travail ou leur travail supervisé), cela peut aider à renforcer votre argument. Encore une fois, vous devez être prêt à vous justifier de manière calme et rationnelle et être en mesure de "s'approprier" les arguments que vous avancez.
À condition que votre direction soit des personnes raisonnables, elles doivent comprendre que ce que vous dites a du mérite si vous pouvez fournir des preuves à l'appui de vos réclamations.
Je pense que vous devriez en effet vous efforcer d'avoir des fonctions avec un petit nombre de SLOC.
Si LOC (lignes de code) est un petit nombre, comment affecte-t-il le code et si LOC est-il un plus grand nombre, comment affecte-t-il le code?
Idéalement, il devrait être plus facile de comprendre 8 lignes de code en un coup d'œil que de comprendre 30.
Cela ne signifie pas que 30 LOC compressés en 8 lignes seront plus faciles à comprendre.
Selon vous, quelle est la bonne façon de faire les choses.
Normalement, dans une fonction, j'essaye de la grouper par niveaux d'abstraction ("code IO ici", "validation ici", "calcul ici" et ainsi de suite).
Ensuite, je l'ai divisé en blocs, séparés par une ligne vierge. Si le code fait plus d'une dizaine de lignes, j'extrais chaque bloc dans une fonction différente (je le fais quand même pour le code qui apparaît plus d'une fois). J'ai entendu un argument sur la rupture des performances de cette façon (appels de fonction inutiles) mais dans la pratique, je n'ai jamais eu de goulot d'étranglement en raison de cela.
Cela dit, j'ai eu des fonctions avec cette extraction effectuée, et après cela, la fonction faisait environ 40 lignes (code C). Si le code est aussi groupé que possible, je ne vois pas de problème avec des fonctions plus longues.
Je pense qu'il est plus important de se concentrer sur un code propre et auto-documenté que sur LOC. Je n'aime pas vraiment votre exemple, car il explique ce que fait le code, sans dire pourquoi. Par exemple, ceci:
boolean sweet_sixteen = (âge == 16);
est assez redondant. Quiconque lit "age == 16" le sait. Je préfère écrire le code comme ceci:
public static boolean companyShouldThrowABigParty(int age) {
return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0)));
}
public static void happyBirthday(int age)
{
System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}
La logique de décider quand lancer la fête est distincte de System.out, peut être testée et elle est facile à comprendre. Plus important encore, cependant, quelqu'un qui lit le code peut comprendre la raison pour laquelle il a été écrit de cette façon ("la société veut organiser une grande fête pour certaines personnes").
Je ne verrais pas le nombre de lignes comme un problème dans des circonstances normales, mais cela peut indiquer des problèmes. Si quelqu'un vous montre une classe avec 1000 lignes de code, alors quelque chose ne va pas avec la façon dont la classe a été faite ou conçue.
Votre exemple pointe vers un cas où un plus grand nombre de lignes de code est logique. Mais c'est cet exemple. Chaque jour, je vois des exemples où le nombre de lignes est attaché au manque de planification
Je pense que moins de lignes de code = code plus lisible
Mais bien sûr, il y a une limite, lorsque vous commencez à réduire/masquer votre code juste pour obtenir moins de lignes.
/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
var num = number+"";
while(num.length < digits){
num='0'+num;
}
return num;
}
C'est une minification la logique reste la même, juste moins lisible. Cela ne devrait pas être fait par des humains, cette minification est faite par une machine pour être lue par une machine.
function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}
Si vous pouvez supprimer un morceau de code et que l'algorithme fait toujours ce qu'il est censé faire, allez-y. Ne minimisez pas votre code, il existe de meilleurs outils pour le faire.
Je ne pense pas que moins de lignes de code == code plus lisible. Cependant, la réalité, qui est très différente de la théorie, est que le code avec un grand nombre de lignes est souvent écrit sans une conception appropriée. Par conséquent, l'exigence de moins de lignes PEUT forcer certains programmeurs à proposer une meilleure conception s'ils en sont capables. La torsion est que de nombreux programmeurs ne le sont pas, alors l'exigence n'aide pas beaucoup.
LOC est une mesure beaucoup plus utile au début d'un projet que pendant la mise en œuvre réelle, je pense. Connaître le LOC par point de fonction vous permet d'estimer l'effort du projet, et à partir de là combien de temps le projet prendra et le nombre optimal de développeurs.
Cela peut également influencer la conception et le choix de la langue: réduire les points de fonction ou passer à une langue avec un LOC/FP inférieur devrait réduire l'effort du projet, toutes choses étant égales par ailleurs.
Les lignes de code elles-mêmes ne sont pas très importantes. Une façon de le voir est de le comparer à la prose. La première réalisation est qu'une propriété importante du code et de la prose (en supposant l'exactitude) est la lisibilité. La lisibilité (et la compréhensibilité) aide à d'autres propriétés telles que la maintenabilité et l'exactitude.
Il y a des avantages à pouvoir adapter une fonction à un petit nombre de lignes. Mais avoir du texte sans paragraphes réduit sa lisibilité. L'utilisation de concepts difficiles, de mots difficiles (rares) et de modes d'expression complexes réduit généralement la quantité de mots nécessaires pour exprimer une idée, mais déplace en même temps le niveau de lecture du texte du niveau secondaire aux universitaires professionnels (dans le cas de prose).
En général, il est utile d'ajouter des abstractions dans votre code et d'utiliser des assistants, etc. mais encore une fois, ces abstractions peuvent devenir trop nombreuses. Ce qui peut également arriver, c'est que déplacer la complexité vers une autre partie du code. Parfois, comme lorsque vous, en tant qu'expert, concevez un cadre/une bibliothèque à l'usage des programmeurs débutants (ou étudiants), c'est une bonne idée de le faire. Mais ne vous attendez pas à ce que les juniors soient en mesure de comprendre comment fonctionne votre code, il est très difficile pour eux de l'utiliser incorrectement.
Lors de l'écriture de code, ne surtout pas hésiter à ajouter des lignes vides dans votre code. Ils fonctionnent comme des paragraphes et vous aident à séparer les différentes parties de votre fonction (même s'ils ne doivent pas encore être placés dans des assistants).