Quelle est l'importance de réduire le nombre de lignes dans le code?

Je suis un développeur de logiciels qui travaille sur J2SE (core java).
Lors de nos révisions de code, on nous demande souvent de réduire le nombre de lignes dans notre code.

Il ne s'agit pas de supprimer le code redondant, mais de suivre un style centré sur le même principe, avec moins de lignes dans le code, tout en ayant la clarté du code, même si cela implique d'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 nombre plus grand, 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 un é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 ce qui est sans importance.

Mesurer le SLOC (ce qui est effectivement ce que font vos avis), donne du SLOC une importance .... Le SLOC est-il important? - Absolument pas, cela ne l’a jamais été (en dehors des concours de programmation obscurcie ), 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 des utilisateurs? Ce qui se produit probablement dans ce cas-ci, c’est que le SLOC est utilisé comme un moyen naïf de mesurer la complexité. Ce qu'il faut éviter à tout prix, c'est de compter les beans faciles à compter - des mesures objectives telles que le SLOC, au lieu de compter les beans importants mais difficiles à compter - par exemple, la lisibilité, la complexité, etc.

Je suis d'accord avec vos critiques de code, mais avec un astérisque. Chaque déclaration que vous écrivez dans votre code est une responsabilité technique - c'est un point de défaillance potentiel. Si vous écrivez une méthode avec 10 instructions et que votre collègue en écrit une qui remplit les mêmes fonctions avec 5 instructions, sa méthode sera probablement meilleure si elle est mesurée par la probabilité de problèmes (il y a deux fois plus d'endroits où votre code peut être erroné, excessivement 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();
}

C'est une ligne de code, mais c'est un endroit où une quantité incroyable de problèmes peut survenir. Je dirais donc que vous devez vous concentrer sur le plus possible avec le moins de déclarations possible: écrivez autant de code que nécessaire pour faire avancer les choses, sans plus. Au moins, je pense que c’est ce que vos réviseurs de code veulent faire.

Personnellement, je pense qu'il y a un équilibre à trouver. Comme je l'ai dit, chaque affirmation que vous écrivez est un passif, mais si extraire une variable locale avec un nom descriptif rend votre méthode beaucoup plus claire et lisible, alors il faut également en tenir compte. Je pense que vous pouvez facilement vous retrouver dans des situations où les gens chicanent au sujet de différences esthétiques relativement mineures, mais dans l’ensemble, je pense que vos critiques ont la bonne idée: préférer réduire au minimum le nombre de problèmes.

Suivre à la lettre les conseils des réviseurs ne servira à rien, car le résultat direct évident est la promotion de lignes tendues (la longueur de ligne n'est pas limitée). Je pense que la leçon à tirer ici, cependant, est de faire en sorte que votre code fasse moins de choses .

En d'autres termes, il s'agit d'un appel à la simplicité. Il est assez courant d' affirmer que le code est un passif et non un actif . Réduire son montant tout en préservant ses fonctionnalités est donc un effort noble. Cela peut être réalisé par une approche directe, plus terre-à-terre, qui s'attaque directement au 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 de "clarifier le code même si cela signifie augmenter le nombre de lignes".

J'ai vu trop de monolithes qui sont assez laconiques, mais ce qu'ils font n'est pas immédiatement évident. La lisibilité est la règle, car les autres développeurs devront maintenir votre code.

Je dirais que mieux vaut viser les méthodes courtes. Pas abrégé pour quelques lignes de code, mais abrégé car ils ne font qu'une seule chose.

Je travaille actuellement en tant que développeur d'applications principal et analyste de projets 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 d'une analyse rapide et d'une correction (ou d'un ajout). Pour moi, lorsque vous êtes en charge d'applications critiques pour les entreprises qui DOIVENT avoir un vaste niveau d'évolutivité et capables d'altérer à la volée dans un environnement en constante évolution, un code concis, facile à lire, est l'un des éléments les plus importants du développement. . Au crédit de la 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 totalement inacceptable pour moi, cependant, j'ai trouvé modifier toutes les entreprises code existant de:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

à:

value.prop =  boolean ? option1 : option2;

était un excellent choix de code condensé qui ne sacrifie pas la lisibilité.

En ce qui concerne comment cela affecte le code? Je n'ai jamais remarqué d'augmentation ou de diminution des performances, par exemple, de 100 lignes de code. En réalité, le processus que vous utilisez pour arriver au produit final est plus important que le nombre de lignes qu'il faut pour y arriver. J'ai vu certains processus écrits très condensés, même s'ils étaient 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 à l’aide d’un simple compte LOC. Il y a beaucoup plus à ce qui fait un code bien conçu et efficace.

D'après mon expérience, code efficace:

• ne casse aucun des principes SOLID
• est lisible et explicite
• passe le test de simplicité d’Albert Einstein: "Tout doit être rendu aussi simple que possible, mais pas plus simple."

Il existe de nombreuses réponses ici qui traitent des avantages et des inconvénients techniques de la réduction du niveau de la LOC et de la question de savoir s’il s’agit ou non d’un indicateur de qualité du logiciel. Ce n'est pas ce que cette question est à propos. Il s’agit de savoir comment traiter avec une direction qui exige une adhésion dogmatique naïve à une règle empirique de codage particulière.

Malheureusement, il est assez courant pour les gens de s’approprier des sujets qui sont de bons conseils s’ils sont utilisés dans le contexte approprié et appliqués de manière pragmatique, sortez-les de ce contexte et appliquez-les dogmatiquement sans négliger les problèmes qu’il existe au départ pour atténuer ces problèmes. .

L’objectif du conseil concernant la réduction de la LDC est d’éviter la création de méthodes qui tentent d’en faire trop, et de décourager la création de "classes divines", qui en savent trop sur les aspects d’un dessin qui ne sont pas leur conception. 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, même si, comme vous l’avez indiqué, vous pouvez en faire trop au point que la lisibilité commence à en souffrir.

Un faible nombre de lettres LOC présente des avantages évidents (les petites méthodes vous tiennent plus à l’esprit que les grandes, moins le code contient moins de problèmes, etc.), mais il est également soumis à la loi des rendements décroissants. Refactoriser une méthode de 150 lignes en un certain nombre de méthodes de 20 lignes est un gain beaucoup plus important que de refactoriser une méthode de 10 lignes en une méthode de 7 lignes.

Lorsque cette refactorisation se fait au détriment d'une autre facette d'une bonne conception logicielle (telle que la lisibilité), vous avez alors atteint un point où vous pouvez justifier de ne pas le faire. Supprimer des variables qui donnent un contexte à la signification du code et les remplacer par des littéraux qui ne le font pas est une très très mauvaise chose à faire. Un bon code n'a 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. Ainsi, si LOC est vénéré comme une sorte de dieu, de telles lignes de clarification risquent fort de faire l’objet d’une élimination rapide et gagnante. des éloges erronés de la part de la direction.

Je pense que vous êtes assez intelligent pour comprendre cela. En fait, c'est en gros le sens de votre question initiale. Le problème ne réside pas dans votre compréhension du moment où la réduction du code est bonne et, dans le cas contraire, le dogmatisme consistant à appliquer ce qui est normalement une pratique raisonnable sans discernement.

Je recommanderais de prendre le temps de discuter avec votre direction, d'expliquer votre position et pourquoi vous pensez que ce que l'on vous demande de faire nuit au code plutôt qu'à l'aider. Essayez d’éviter la confrontation, 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 meilleures pratiques ne sont utiles que si elles sont appliquées de manière pragmatique. La meilleure pratique est écrite dans un livre, non gravé dans la pierre, et en cas de conflit (code court par rapport à un code lisible), il appartient au programmeur d’exprimer son jugement quant à la meilleure pratique à suivre. Espérons que ce sont des personnes raisonnables qui apprécient une telle contribution.

Vous devez également être un peu courageux, car si des pressions sont exercées sur vous pour réduire le niveau de la possession lorsque vous pensez que cela est inutile ou inapproprié, il est tout à fait naturel que vous apportiez ce changement pour une vie tranquille. Vous devez résister à cela, et vous devez "posséder" cette décision. Dans une situation où la direction est raisonnable, vous ne devriez pas être obligé de respecter ses directives à la lettre, mais vous devriez pouvoir justifier des circonstances dans lesquelles vous ne le faites pas.

Malheureusement, les gens peuvent être irrationnels, en particulier quand il s'agit de gens moins scrupuleux qui remettent 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 être préparé pour cela aussi. Si vous pouvez démontrer des cas où la meilleure pratique de la LOC entre en conflit direct avec d’autres, expliquez pourquoi cela nuit au produit et si vous pouvez le faire dans des parties de la base de code pour lesquelles ils n’ont que peu ou pas ne semble pas être une attaque personnelle contre leur travail ou le travail qu’ils ont supervisé), cela peut aider à renforcer votre argumentation. Encore une fois, vous devez être prêt à vous justifier de manière calme et rationnelle et à "posséder" les arguments que vous avancez.

Si vos dirigeants sont des personnes raisonnables, ils doivent comprendre que ce que vous dites est valable si vous pouvez fournir des preuves pour étayer vos revendications.

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 nombre plus grand, comment affecte-t-il le code?

Idéalement, il devrait être plus facile de comprendre d'un coup d'œil 8 lignes de code que de comprendre 30.

Cela ne signifie pas que 30 LOC compressés sur 8 lignes seront plus faciles à comprendre.

Selon vous, quelle est la bonne façon de faire les choses?

Normalement, dans une fonction, j'essaie de la regrouper par niveaux d'abstraction ("code IO ici", "validation ici", "calcul ici", etc.).

Ensuite, je l'ai divisé en blocs, séparés par une ligne vide. Si le code dépasse 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 possibilité de casser les performances de cette façon (appels de fonction inutiles), mais en pratique, cela ne m'a jamais causé de goulet d'étranglement.

Cela dit, cette extraction s’est faite avec des fonctions et après, la fonction avait une longueur de ~ 40 lignes (code C). Si le code est aussi regroupé que possible, les fonctions plus longues ne me posent aucun problème.

Je pense qu'il est plus important de se concentrer sur du code propre et auto-documenté que sur LOC. Cependant, je n'aime pas beaucoup votre exemple, car il explique ce que fait le code sans dire pourquoi. Par exemple, ceci:

booléen sweet_sixteen = (age == 16);

est assez redondant. Tous ceux qui lisent "age == 16" le savent. Je préférerais é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 permettant de décider quand lancer la fête est distincte de System.out, peut être testée et est facile à comprendre. Plus important encore, une personne lisant le code peut comprendre la raison pour laquelle il a été rédigé de cette manière ("la société souhaite organiser une grande fête pour certaines personnes").

Je pense que moins de lignes de code = code plus lisible

Mais bien sûr, il y a une limite lorsque vous commencez à minimiser / obscurcir votre code simplement pour avoir 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, mais moins lisible. Cela ne devrait pas être fait par des humains, cette minification est faite par 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 continue de faire ce qu'il est censé faire, ok, poursuivez. Ne minimisez pas votre code, il existe de meilleurs outils pour le faire.

Je ne pense pas 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, la nécessité d'avoir moins de lignes PEUT forcer certains programmeurs à améliorer la conception s'ils en sont capables. Le problème, c’est que de nombreux programmeurs ne le sont pas. L’exigence n’aide donc pas grand chose.

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é conçue ou conçue.

Votre exemple indique un cas où un plus grand nombre de lignes de code a du sens. Mais c'est cet exemple. Chaque jour, je vois des exemples où le nombre de lignes est associé à un manque de planification

La LOC est une mesure beaucoup plus utile au début d'un projet que lors de la mise en œuvre réelle, je pense. Connaître la LOC par point de fonction vous permet d’estimer l’effort du projet, ainsi que sa durée et le nombre optimal de développeurs.

Cela peut également influer sur la conception et le choix de la langue: la réduction des points de fonction ou le passage à une langue avec une LOC / PF inférieure 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 voir les choses est de comparer cela avec la prose. La première réalisation est que la lisibilité est une propriété importante du code et de la prose (en supposant que ce soit correct). La lisibilité (et la compréhensibilité) aide avec d'autres propriétés telles que la maintenabilité et l'exactitude.

Il est avantageux d’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 moyens d’expression complexes réduit généralement le nombre de mots nécessaires pour exprimer une idée, mais déplace parallèlement le niveau de lecture du texte du niveau secondaire aux universitaires cas de prose).

En général, il est utile d’ajouter des abstractions dans votre code et d’utiliser des assistants, etc., mais là encore, ces abstractions peuvent devenir trop nombreuses. Ce qui peut également arriver, c’est que la complexité passe à une autre partie du code. Parfois, comme lorsque vous concevez, en tant qu’expert, un cadre / une bibliothèque destiné aux programmeurs débutants (ou aux étudiants), c’est une bonne idée de le faire. Mais ne vous attendez pas à ce que les juniors soient en mesure de comprendre le fonctionnement de votre code. Simplement, il leur sera très difficile de l'utiliser de manière incorrecte.

Lorsque vous écrivez du code, n'hésitez surtout pas à 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 si elles ne doivent pas encore être insérées dans les assistants).

Le grand problème avec chaque méthode formelle d’évaluation de code est qu’elle échouera sur certains codes. En effet, la programmation est une sorte d’art et, en tant que tel, il ne peut pas exister de normes claires en matière d’évaluation. Bien sûr, il existe différents types d'art - la production en série de peintures existe aussi, et peut-être que dans ce secteur est important le nombre de peintures dépensées pour une peinture. :)

Pour être parfaitement honnête, je me fiche de la mesure de la LOC. Bien sûr, il est bien qu’une fonction ou une procédure soit aussi courte que possible, mais je prends du code lisible sur toute heure de la journée.

Je conviens que le fait de toujours exiger une réduction de la marge de crédit conduirait à un code difficile à lire.

Cependant, votre style de codage est peut-être trop détaillé et votre critique pense qu'une méthode plus concise est préférable. Par exemple, un commentaire qui n’explique qu’une affirmation assez évidente grâce au choix clair des noms de variables est inutile.

Les lignes de code mesurent une seule chose, c'est le nombre de lignes de code que vous avez. Tout le reste n'est que de l'air chaud, de la spéculation et des préjugés.

Il existe de nombreux exemples intéressants dans les autres réponses montrant que le fait de réduire le nombre de lignes de code peut aggraver quelque chose, mais pas améliorer, mais un point essentiel semble avoir été oublié: combien de lignes avez-vous réellement besoin pour faire ce travail? ?

Si vous avez besoin de 10 lignes de code pour accomplir votre tâche, faites-le en 10 lignes. Si vous avez besoin de 10 000 lignes, vous le ferez également en 10 000 lignes. Le culte de "moins de lignes de code" n'améliorera pas le dernier exemple si vous le faites en 1 000, 2 000 ou autre. La tâche nécessitait 10 000 lignes et ces 10 000 lignes peuvent inclure des couches de validation, de vérification des erreurs, de sécurité, etc., qui seraient omises si vous les exécutiez en moins.

Modifier

Depuis que cela a recueilli quelques critiques négatives, je pense que je dois être plus précis sur ce que je dis ici. La première chose à faire est de lire ceci . Ce que je vous demande d’évoquer, c’est que le code de haut niveau que vous écrivez n’a que peu, voire aucune ressemblance, avec le code machine qui est réellement exécuté. La pertinence de ce point est qu’il est erroné de se concentrer sur le code de haut niveau sans comprendre ce qui se passe réellement en dessous.

Considérons maintenant ce qui suit:

• Il est possible d'écrire du code très lent et très lent avec une seule ligne - notez le commentaire sur l'opérateur ternaire à la fin du lien que j'ai fourni.

• Si une ligne de code passe un appel API (ou un autre appel dans une bibliothèque externe), vous avez par définition peu de contrôle direct sur ce qui est exécuté ou sur son efficacité.

• La vérification des erreurs, nettoyage, etc tous les ajouter des lignes de code supplémentaires et je suis tout à fait certain que même les fans les plus ardents de moins de lignes de code ne serait pas argumenter contre ceux .

So - les lignes de code sont une métrique cassée. Moins de lignes de code ne garantit pas des performances supplémentaires: cet appel d'API ou de bibliothèque ne représente qu'une ligne et peut échapper à votre contrôle. Moins de lignes de code ne garantit pas une robustesse supplémentaire - la vérification des erreurs et le nettoyage nécessiteront toujours des lignes supplémentaires. Moins de lignes de code ne garantit même pas une lisibilité ou une maintenabilité supplémentaire - il suffit de consulter le code IOCCC pour le savoir.

Alors, que garantit moins de lignes de code? Moins de lignes de code, c'est tout.

Il est très mal de se concentrer sur le même travail avec 2 000 lignes contre 10 000. Concentrez-vous plutôt sur un code qui fonctionne, qui est robuste, qui respecte les tolérances acceptées, et qui est plus facile à lire et à conserver. Parfois, cela signifie que vous pouvez le faire avec un nombre de lignes de crédit faible, parfois que vous devez le faire avec un nombre de lettres de crédit plus élevé, mais le nombre de lignes de crédit ne devrait pas être ce qui est important ici.

Quelle est l'importance de réduire le nombre de lignes dans le code? Dans la plupart des cas, pas du tout. En fait, dans la plupart des cas, il est plus important d’augmenter le nombre de lignes de code en divisant les opérations complexes en étapes plus lisibles, en commentant chaque étape et en ajoutant des commentaires en général pour rendre le code plus lisible et extensible par d’autres. Les développeurs qui viennent après vous.

Auparavant, on supposait que si le nombre de lignes de code localisées est important, le code est efficace et accomplit toutes les tâches pour lesquelles il est habitué, mais il a été réalisé au bout d'un certain temps que moins le locus était local, plus il a l'efficacité, car le coût supporté par le système pour exécuter le code est très inférieur.Ainsi, l'amélioration du système local devait être réduite. Depuis, on supposait que le système local devait être moindre.Pour le réduire, les facteurs suivants devrait être pris en compte.

1. Faites un organigramme de votre problème
2. Essayez d'utiliser moins de boucles que vous le pouvez
3. Les appels de fonction ne devraient pas être beaucoup
4. De nouvelles structures de données telles que TRIE doivent être utilisées dans le cas où une pile ou une file d'attente est utilisée pour stocker les informations pertinentes.
5. Et essayez de résoudre le problème avec une approche réaliste plutôt qu'avec une approche imaginative dans laquelle vous stockez une quantité énorme de nombres dans un très grand tableau et essayez ensuite d'y accéder par le biais du tableau.]
6. Utilisez autant de macros que possible. En outre, l'approche à utiliser dépend également du problème.Si c'est vraiment complexe, utiliser parfois l'approche simple équivaut également à l'approche complexe.