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

85

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.");
    }
}
réduction
la source
63
Je peux transformer n'importe quel fichier java en une seule ligne de code ( s/\n/ /g) cela ne signifie pas qu'il sera même lisible à distance
freak freak
6
Votre entreprise utilise-t-elle le LOC pour mesurer la productivité, de sorte qu'elle essaie de vous empêcher de «jouer au système» avec ses normes de codage?
JeffO
29
Ce serait vraiment utile si vous pouviez fournir un bref exemple de chaque style (non choisi), afin que tout le monde comprenne clairement de quoi nous parlons. Il y a des extrêmes dans les deux sens; et la réponse dépendra beaucoup de votre contexte.
Daniel B
3
Nettoyez toujours votre chambre, puis votre mère entre et dit "ce n'est pas propre" et indique 10 choses que vous n'avez pas rangées. C'est essentiellement ce qu'ils vous disent dans la révision du code.
Reactgular
11
L'exemple que vous avez donné est presque une version de manuel du refactoring Introduce Explaining Variable , qui augmente généralement la lisibilité et l'intention (ce qui est une bonne chose). Certains diront que vous devriez reformuler les variables plus loin en fonctions courtes et à une ligne, mais cela va à l'extrême; Je dirais que votre version est préférée à la version courte recommandée par la critique.
Daniel B

Réponses:

75

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.

mattnz
la source
33
Bien que la description de l'examen par OP donne un son un peu inutile, je dirais que les lignes de code sont souvent liées aux mesures plus dures que vous avez mentionnées. Les fonctions longues sont souvent moins lisibles et ont souvent une complexité cyclomatique plus élevée. Donc, il faut vraiment savoir si l'examen recommande réellement de diviser / raccourcir le code pour en tirer profit, ou s'il s'agit simplement de suggérer l'inclusion de plusieurs lignes légitimes.
Daniel B
3
Je dirais que pour réduire le nombre de lignes de code, il est important de pouvoir afficher davantage de fonctions sur une seule page. Plus il est facile de visualiser une méthode ou une classe sans avoir besoin de faire défiler, plus il est facile de conserver le contexte dans votre tête.
CLandry
2
@DanielB Les fonctions longues sont souvent plus difficiles à comprendre, car elles sont longues; mais parce qu'ils tentent de faire beaucoup de choses à la fois. Par exemple, ils commencent généralement par la validation des entrées, puis par certains traitements, suivis d'un contrôle pour un traitement alternatif, suivi d'un autre contrôle pour voir si quelque chose non lié nécessite une mise à jour, suivi d'une routine en ligne qui n'a rien à voir avec l'action principale ( comme la logique de date qui vérifie le mois écoulé et ajuste) et ainsi de suite. Au moment où vous arrivez à la fin, vous ne pouvez pas vous souvenir de la responsabilité de la classe.
Edwin Buck
1
@Clandry: Maintenir le contexte en le faisant tenir sur une page est une très mauvaise raison de réduire le SLOC. Il est sûrement plus facile de conserver le contexte si le code est bien présenté et plus facile à lire. - Qu'est-ce qu'une "page" 2500 ou 1000 pixels? J'ai un moniteur 2 * 30 "en portrait, mais je développe parfois sur un ordinateur portable.
mattnz
4
Les études qui montrent (réf. A) LOC === Les bugs sont un sou par douzaine. C'est un fait bien connu et accepté. Ce qui n’a pas été démontré (à ma connaissance) est (réf. B) "Réduire le LOC dans une base de code === Réduire les bogues dans cette base de code". L'extrapolation (réf. A) à la revendication (réf. B) n'est pas scientifique. Publier un document qui prouve ou réfute la relation serait.
mattnz
84

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.

Erik Dietrich
la source
4
D'accord - réduire le nombre d'instructions peut être utile, mais jusqu'à un certain point, si l'examen du code veut réduire le nombre d'instructions, ne dirait-il pas simplement "moins d'énoncés" plutôt que "moins de lignes de code".
mattnz
1
@mattnz seulement à coup sûr s'ils sont pédants.
Dan Neely
2
Dans mon expérience, quelqu'un qui peut écrire le même algorithme en moins d'instructions va a) utiliser des choses qui ne sont pas très communes ou qui ne sont pas très bien comprises, et b) introduire plus de cas extrêmes nécessitant des tests unitaires et pouvant présenter des bugs. Bien entendu, cela suppose que les deux programmeurs ont une capacité à peu près égale.
Daniel AA Pelsmaeker
13
+1 pour la chaîne d’appel de fonctions humoreusement longue, et le support double furtif après violations().
Joe Z.
5
100% +1, tant de gens ne comprennent pas les conséquences de chaque bit de code supplémentaire ajouté à une base de code. C'est une chose que les gens doivent vraiment connaître.
Jimmy Hoffa
32

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 .

Xion
la source
21

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.

jhewlett
la source
12

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.

Joshua Volearix
la source
Vous voulez direvalue.prop = boolean ? option1 : option2;
Christoffer Hammarström
Je fais! ... sur le "code condensé" de toute façon.
Joshua Volearix
2
Votre deuxième exemple est particulièrement utile, car il est non seulement plus simple, mais il est également plus clair qu’il s’agit de l’affectation de l’une des deux options, sans aucun effet secondaire. Le if-then-elseobscurcit cela; par exemple, il est trop facile d’affecter une variable différente dans chaque branche de la if(ce qui peut être une erreur ou non, mais c’est difficile à repérer).
Andres F.
J'ai rencontré des environnements où l'utilisation de l'opérateur ternaire était expressément interdite. C'étaient généralement des environnements en transition de PL / SQL ou similaires à Java où les gens avaient peur de la tersité ... En ce qui concerne l'affirmation selon laquelle l'écriture de code supplémentaire n'a pas d'incidence sur les performances, il peut exister une dépendance en fonction de la nature du code. Si vous remplacez un opérateur par un appel de méthode, par exemple, il y a certainement un impact (et ce peut être un impact sérieux).
Jwenting
9

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."
Dino Octavian
la source
1
+1 pour la citation d'Einstein.
Justsalt
6

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.

GordonM
la source
2

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.

utnapistim
la source
2

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").

Eduardo Scoz
la source
2
La signification de la douce seize ans (et de l'âge de 21 ans) est spécifique à la culture. L'expression "sweet sixteen" est plus consultable que "age == 16". Pour cette raison, donner des noms à certains booléens pourrait être utile. Je suis cependant d'accord avec votre sentiment général: ne perdez pas de temps à expliquer un code explicite.
Jonas Kölker
1

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.

Vitim.us
la source
1

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.

zhouji
la source
1

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

IvoC
la source
0

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.

James Jensen
la source
0

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).

Paul de Vrieze
la source
-1

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. :)

johnfound
la source
-1

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.

Vladimir Kocjancic
la source
-2

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.

MatthieuW
la source
5
Autant que je sache, les commentaires ne comptent pas pour le COL.
Mhr
1
Cela ne compte pas ou compte, selon la définition que vous utilisez.
Matthieu
1
Les commentaires sont des commentaires. Ils ne sont pas du code. Par conséquent, ils ne s'appliquent pas aux comptes LOC. Bien que le code auto-documenté soit préférable à du code bien commenté, supprimer des commentaires moins évidents d’un code n’aide personne.
GordonM
-2

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.

révolutions mh01
la source
1
Par définition , si une tâche nécessite absolument N lignes de code à accomplir (ce qui est difficile à déterminer en premier lieu), elle ne peut pas être effectuée en moins de N lignes. Votre tâche de 10 000 lignes ne peut donc pas être effectuée sur 2 000, point à la ligne. Je suppose que le PO parle des cas où il y a une marge de manœuvre, c'est-à-dire "l'exigence peut être pleinement remplie dans les deux sens, alors laquelle est la meilleure?"
Andres F.
-3

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.

Infin8Loop
la source
1
Pourquoi tous les votes négatifs?
Marko
Oui, pourquoi une réponse parfaitement sensée a-t-elle été votée? Pourquoi d'autres réponses parfaitement sensées ont-elles toutes remis en cause l'idée selon laquelle les lignes de code réduites sont une fin en soi, également négativement?
Maximus Minimus
1
@ mh01 Je devine parce que la plupart de celui-ci est faux? Plus précisément, ce in most cases, it is more important to increase the number of lines of code by breaking out complex operations into more readable stepsn’est pas mon expérience. Le code complexe peut plus souvent être rendu plus lisible et moins bogué en le rendant plus petit et plus simple, car il devait être complexe du fait qu’il était écrit par une personne qui connaissait peu le langage / qui connaissait le problème / qui ne savait pas vraiment ce qu’elle faisait.
Izkata
-5

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.
Vibhu Tiwari
la source
5
-1: Waouh! Je pense que vous devez réduire le LOC dans votre réponse! Ça me fait mal aux yeux de le lire!
Jim G.
1
@JimG .: Je conviens que la réponse me fait mal aux yeux, mais pense qu'il est préférable de résoudre ce problème en augmentant le LOC (par exemple, en utilisant une ligne distincte pour chaque élément numéroté).
Brian
C'était une faute de l'autoformatter, insérant une seule ligne vierge avant que la liste ne guérisse la situation
Balog Pal