Wie wichtig ist es, die Anzahl der Codezeilen zu reduzieren?

85

Ich bin ein Softwareentwickler, der an J2SE (Core Java) arbeitet.
Oft werden wir während unserer Codeüberprüfungen gebeten, die Anzahl der Zeilen in unserem Code zu reduzieren.

Es geht nicht darum, redundanten Code zu entfernen, es geht darum, einem Stil zu folgen, der sich darauf konzentriert, dasselbe mit weniger Zeilen im Code zu tun, während ich an Klarheit im Code glaube, auch wenn es bedeutet, die Anzahl der Zeilen zu erhöhen.

Was ist Ihrer Meinung nach die richtige Vorgehensweise?
Wenn LOC (Lines of Code) eine kleine Zahl ist, wie wirkt es sich auf den Code aus? Wenn LOC eine größere Zahl ist, wie wirkt es sich auf den Code aus?

Beispiel von der Website: "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.");
    }
}

VS

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.");
    }
}
Ankit
quelle
63
Ich kann jede Java-Datei in eine einzige Codezeile umwandeln ( s/\n/ /g), was nicht heißt, dass sie auch nur aus der Ferne lesbar ist
Ratschenfreak
6
Verwendet Ihr Unternehmen LOC zur Messung der Produktivität, um zu verhindern, dass Sie das System mit seinen Codierungsstandards "spielen"?
JeffO
29
Es wäre wirklich hilfreich, wenn Sie ein kurzes Beispiel für jeden Stil liefern könnten (nicht von Kirschen gepflückt), damit jeder weiß, wovon wir sprechen. In beiden Richtungen gibt es Extreme. und die Antwort wird in hohem Maße von Ihrem Kontext abhängen.
Daniel B
3
Immer dein Zimmer putzen, dann kommt deine Mutter herein und sagt "das ist nicht sauber" und weist auf 10 Dinge hin, die du nicht weggeräumt hast. Das ist im Grunde, was sie Ihnen in der Codeüberprüfung sagen.
Reactgular
11
Das Beispiel, das Sie angegeben haben, ist beinahe eine Lehrbuchversion des Refactorings " Introduce Explaining Variable" , das in der Regel die Lesbarkeit und Zweckmäßigkeit erhöht (was gut ist). Einige würden argumentieren, dass Sie die Variablen weiter in kurze, einzeilige Funktionen umgestalten sollten, aber das bringt es auf ein Extrem; Ich würde sagen, dass Ihre Version der von der Rezension empfohlenen Version vorgezogen wird.
Daniel B

Antworten:

75

Das Problem bei Messungen, egal wie gut sie gemeint sind, ist, dass die eigentliche Messung des Gegenstands ihn wichtig macht, und die Konsequenz daraus, dass ein Gegenstand nicht gemessen wird, macht ihn unwichtig. Es ist absolut wichtig zu messen, was wichtig ist, und nicht, was unwichtig ist.

Das Messen des SLOC (was genau Ihre Bewertungen bewirken) macht den SLOC wichtig ... Ist der SLOC wichtig? - Absolut nicht, niemals (Outside Obfuscated Programming Contests ), niemals in einer kommerziellen Organisation.

Stellen Sie sich eine einfache Frage: Wie kann "Reduzieren Sie den SLOC dieser Routine" jeden Code verbessern? In diesem Fall geschieht wahrscheinlich, dass SLOC als naive Methode zur Messung der Komplexität verwendet wird. Was Sie unbedingt vermeiden müssen, ist das Zählen der einfach zu zählenden Bohnen - objektive Maßnahmen wie SLOC, anstatt die wichtigen, aber schwer zu zählenden - zB Lesbarkeit, Komplexität usw.

mattnz
quelle
33
Während die Beschreibung der Überprüfung durch OP ein wenig sinnlos klingt, würde ich sagen, dass Codezeilen häufig mit den von Ihnen erwähnten härteren Maßnahmen zusammenhängen. Lange Funktionen sind oft weniger lesbar und weisen auch häufig eine höhere zyklomatische Komplexität auf. Es kommt also wirklich darauf an, ob in der Überprüfung tatsächlich empfohlen wird, Code, der davon profitieren würde, aufzubrechen / zu verkürzen, oder ob nur das Einfügen mehrerer legitimer Zeilen empfohlen wird.
Daniel B
3
Ich würde sagen, dass der Grund, warum es wichtig ist, die Anzahl der Codezeilen zu reduzieren, darin besteht, mehr Funktionen auf einer einzelnen Seite anzuzeigen. Je einfacher es ist, eine Methode oder Klasse anzuzeigen, ohne einen Bildlauf durchführen zu müssen, desto einfacher ist es, den Kontext in Ihrem Kopf zu verwalten.
CLandry
2
@DanielB Lange Funktionen sind oft schwerer um den Kopf zu legen, nicht weil sie lang sind. aber weil sie versuchen, viele Dinge gleichzeitig zu tun. Zum Beispiel beginnen sie im Allgemeinen mit der Validierung von Eingaben, dann mit einer Verarbeitung, gefolgt von einer Prüfung auf alternative Verarbeitung, gefolgt von einer weiteren Prüfung, um festzustellen, ob etwas anderes aktualisiert werden muss, gefolgt von einer eingebetteten Routine, die nichts mit der Hauptaktion zu tun hat ( wie eine Datumslogik, die prüft, ob ein Monat überschritten ist und sich anpasst) und so weiter. Bis Sie am Ende angekommen sind, können Sie sich nicht erinnern, welche Verantwortung die Klasse hatte.
Edwin Buck
1
@ CLandry: Die Aufrechterhaltung des Kontexts durch Anpassung auf eine Seite ist ein sehr schlechter Grund, den SLOC zu reduzieren. Sicherlich ist es einfacher, den Kontext zu pflegen, wenn der Code übersichtlich und besser lesbar ist. - Was ist eine "Seite" 2500 oder 1000 Pixel? Ich habe 2 * 30 "-Monitore im Hochformat, entwickle sie aber manchmal auf einem Laptop.
Mattnz
4
Studien, die zeigen, (ref a) LOC === Bugs sind ein Dutzend. Es ist eine bekannte und akzeptierte Tatsache. Was (meines Wissens) nicht gezeigt wurde, ist (ref b) "LOC in einer Codebasis reduzieren === Bugs in dieser Codebasis reduzieren". Die Extrapolation (a) auf Anspruch (b) ist unwissenschaftlich. Ein Papier zu veröffentlichen, das die Beziehung beweist oder widerlegt, wäre.
Mattnz
84

Ich stimme Ihren Code-Reviewern zu, aber mit einem Sternchen. Jede Aussage, die Sie in Ihren Code schreiben, stellt eine technische Haftung dar - es ist eine potenzielle Fehlerquelle. Wenn Sie eine Methode mit 10 Anweisungen schreiben und Ihr Kollege eine, die dieselbe Funktionalität mit 5 Anweisungen erzielt, schreibt, ist diese wahrscheinlich "besser", gemessen an der Wahrscheinlichkeit von Problemen (es gibt doppelt so viele Stellen, an denen Ihr Code falsch sein kann, allzu oft) komplex oder problematisch).

Hier ist jedoch das Sternchen. Es geht nicht um die tatsächliche Anzahl der Codezeilen in der Idee, da Sie die Anzahl der Zeilen mit etwas wie Folgendem reduzieren können:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

Dies ist eine Codezeile, aber es ist ein Ort, an dem eine erstaunliche Menge von Dingen schief gehen kann. Ich würde sagen, konzentrieren Sie sich darauf, mit den wenigsten Anweisungen das Meiste zu erreichen - schreiben Sie so viel Code, wie Sie benötigen, um Dinge zu erledigen, und nicht mehr. Zumindest denke ich, dass dies das ist, was Ihre Code-Reviewer anstreben.

Ich persönlich denke, es gibt ein Gleichgewicht zu finden. Wie ich bereits sagte, ist jede Anweisung, die Sie schreiben, eine Verbindlichkeit. Wenn Sie jedoch eine lokale Variable mit einem beschreibenden Namen herausziehen, wird Ihre Methode viel klarer und lesbarer, dann gibt es auch dafür einen Grund. Ich denke, man kann leicht in Situationen geraten, in denen sich die Leute über relativ kleine ästhetische Unterschiede streiten, aber im Großen und Ganzen denke ich, dass Ihre Rezensenten die richtige Idee haben - es zu bevorzugen, die Anzahl der Dinge zu minimieren, die schief gehen können.

Erik Dietrich
quelle
4
Einverstanden sein - die Anzahl der Anweisungen zu reduzieren, kann bis zu einem gewissen Grad nützlich sein. Wenn die Codeüberprüfung jedoch die Anzahl der Anweisungen reduzieren möchte, würden sie nicht einfach "weniger Anweisungen" anstelle von "weniger Zeilen von" sagen Code".
Mattnz
1
@mattnz nur sicher, wenn sie pedantisch sind.
Dan Neely
2
Nach meiner Erfahrung wird jemand, der denselben Algorithmus in weniger Anweisungen schreiben kann, a) Dinge verwenden, die nicht sehr verbreitet oder nicht sehr gut verstanden sind, und b) mehr Randfälle einführen, die Komponententests erfordern und Fehler verursachen können. Dies setzt natürlich voraus, dass beide Programmierer ungefähr gleich gut sind.
Daniel AA Pelsmaeker
13
+1 für die humorvoll lange Funktionsaufrufkette und die hinterhältige doppelte Klammer danach violations().
Joe Z.
5
100% +1, so dass viele Leute die Konsequenzen jedes zusätzlichen Codes, den sie zu einer Codebasis hinzufügen, nicht verstehen. Dies ist etwas, über das die Leute wirklich Bescheid wissen müssen.
Jimmy Hoffa
32

Die Ratschläge der Prüfer im wahrsten Sinne des Wortes zu befolgen, nützt nichts, da das offensichtliche direkte Ergebnis darin besteht, knappe Einzeiler zu fördern (ungeachtet der Begrenzung der Zeilenlänge). Ich glaube, die Lektion, die hier gelernt werden muss, ist , Ihren Code weniger Dinge tun zu lassen .

Mit anderen Worten, dies ist ein Aufruf zur Einfachheit. Es ist eine weit verbreitete Behauptung, dass Code eine Verbindlichkeit und kein Aktivposten ist. Daher ist es eine große Anstrengung , die Menge zu reduzieren und gleichzeitig die Funktionalität zu erhalten. Dies kann durch einen direkten, bodenständigeren Ansatz erreicht werden, der sich direkt mit dem Problem befasst und prägnante Lösungen bevorzugt.

Wie Ken Thompson einmal sagte: Einer meiner produktivsten Tage war es, 1000 Codezeilen wegzuwerfen .

Xion
quelle
21

Ich stimme Ihrer Meinung zu, "Klarheit im Code zu haben, auch wenn es bedeutet, die Anzahl der Zeilen zu erhöhen".

Ich habe zu viele Einzeiler gesehen, die ziemlich knapp sind, aber es ist nicht sofort ersichtlich, was sie tun. Lesbarkeit ist das A und O, da andere Entwickler Ihren Code warten müssen.

Ich würde argumentieren, dass es besser ist, kurze Methoden anzustreben. Nicht zu kurz für wenige Codezeilen, sondern zu kurz, weil sie eine einzige Aufgabe erfüllen.

jhewlett
quelle
12

Ich arbeite derzeit als leitender Anwendungsentwickler und Projektgeschäftsanalytiker für ein großes Unternehmen und habe nie die Zeilenanzahl meiner Entwicklung im Mittelpunkt des Interesses gestanden. Ich glaube jedoch, dass ein Code umso besser sein kann, je komprimierter er ist, ABER nicht auf Kosten der schnellen Analyse und Korrektur (oder Ergänzung). Wenn Sie für geschäftskritische Anwendungen zuständig sind, die ein hohes Maß an Skalierbarkeit aufweisen und in einer sich ständig ändernden Umgebung Änderungen im Handumdrehen vornehmen müssen, ist für mich prägnanter, einfach zu lesender Code eines der wichtigsten Elemente in der Entwicklung . Dank der Antwort von Erik Dietrich :

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

wäre für mich völlig inakzeptabel, jedoch stellte ich fest, dass sich der gesamte im Unternehmen vorhandene Code von:

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

zu:

value.prop =  boolean ? option1 : option2;

war eine ausgezeichnete Wahl für die Codekondensierung, die die Lesbarkeit nicht beeinträchtigt.

Wie wirkt es sich auf den Code aus? Ich habe noch nie eine Leistungssteigerung oder -senkung von beispielsweise 100 Codezeilen bemerkt. Die einfache Tatsache ist, dass es mehr der Prozess ist, den Sie verwenden, um zum Endprodukt zu gelangen, als die Anzahl der Linien, die erforderlich sind, um dort anzukommen. Ich habe gesehen, dass einige Prozesse, die sehr komprimiert, jedoch ineffizient, geschrieben wurden, anders ablaufen als längere Codes mit besserem Code-Fluss.

Joshua Volearix
quelle
Sie meinenvalue.prop = boolean ? option1 : option2;
Christoffer Hammarström
Ich mache! ... sowieso auf den "gekürzten Code".
Joshua Volearix
2
Ihr zweites Beispiel ist besonders gut, weil es nicht nur einfacher ist, sondern auch klarer macht, dass es sich um eine Zuweisung einer von zwei Optionen handelt, ohne Nebenwirkungen. Das if-then-elseverdunkelt dies; Zum Beispiel ist es allzu einfach, in jedem Zweig der eine andere Variable zuzuweisen if(was vielleicht ein Fehler ist oder nicht, aber schwer zu erkennen).
Andres F.
Ich bin auf Umgebungen gestoßen, in denen die Verwendung des ternären Operators ausdrücklich verboten war. Normalerweise handelte es sich um Umgebungen, die sich im Übergang zu PL / SQL befanden oder Java ähnelten, in denen die Leute Angst vor der Knappheit hatten ... Was Ihre Aussage betrifft, dass das Schreiben von weiterem Code keinen Einfluss auf die Leistung hat, kann dies davon abhängen, um welchen Code es sich handelt. Wenn Sie beispielsweise einen Operator durch einen Methodenaufruf ersetzen, hat dies definitiv Auswirkungen (und möglicherweise auch schwerwiegende Auswirkungen).
6.
9

IMO, es ist eine schlechte Idee, die Code-Effektivität anhand einer trivialen LOC-Zählung zu messen. Es gibt noch viel mehr, was richtig konstruierten und effektiven Code ausmacht.

Nach meiner Erfahrung effektiver Code:

  • verletzt keines der SOLID-Prinzipien
  • ist lesbar und selbsterklärend
  • besteht Albert Einsteins Test der Einfachheit: "Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher."
Dino Octavian
quelle
1
+1 für das Einstein-Zitat.
Justsalt
6

Hier gibt es viele Antworten, die sich mit den technischen Vor- und Nachteilen befassen, LOC niedrig zu halten und ob es sich um eine aussagekräftige Qualitätssoftwaremetrik handelt oder nicht. Darum geht es in dieser Frage nicht. Es geht darum, wie man mit Management umgeht, das auf einer naiven dogmatischen Einhaltung einer bestimmten Kodierungsregel besteht.

Leider ist es ziemlich üblich, dass sich Menschen an Dinge klammern, die gute Ratschläge sind, wenn sie im richtigen Kontext verwendet und pragmatisch angewendet werden, sie aus diesem Kontext herausnehmen und dogmatisch anwenden, ohne die Probleme zu würdigen, die der Ratschlag überhaupt zu mildern gibt .

Die Absicht von Ratschlägen zur LOC-Unterdrückung besteht darin, die Schaffung von Methoden zu vermeiden, die versuchen, zu viel auf einmal zu tun, und die Schaffung von "Gottklassen" zu unterbinden, die zu viel über Aspekte eines Entwurfs wissen, die nicht von ihnen stammen direkte Verantwortung und wovon alle anderen Klassen im System abhängig sind. Ein weiterer Vorteil von kürzerem Code ist, dass er besser lesbar ist. Sie haben jedoch darauf hingewiesen, dass Sie ihn übertreiben können, bis die Lesbarkeit tatsächlich leidet.

Niedrige LOC-Werte haben offensichtliche Vorteile (kleine Methoden passen leichter in Ihren Kopf als große, weniger Code-Elemente bedeuten weniger Fehlfunktionen usw.), unterliegen jedoch auch dem Gesetz der sinkenden Renditen. Das Umgestalten einer 150-Zeilen-Methode in eine Anzahl von 20-Zeilen-Methoden ist ein viel größerer Gewinn als das Umgestalten einer 10-Zeilen-Methode in eine 7-Zeilen-Methode.

Wenn ein solches Refactoring auf Kosten eines anderen Aspekts guten Software-Designs (z. B. der Lesbarkeit) geht, haben Sie einen Punkt erreicht, an dem Sie es rechtfertigen können, dies nicht zu tun. Das Entfernen von Variablen, die den Bedeutungen des Codes einen Kontext geben, und das Ersetzen durch Literale, die dies nicht tun, ist eine sehr, sehr schlechte Sache. Guter Code enthält fast keine Literale. Bei diesen Variablen (und benannten Konstanten) handelt es sich jedoch um Codezeilen, die keinen direkten Beitrag zum Programm leisten. Wenn also LOC als eine Art Gott verehrt wird, besteht die große Gefahr, dass solche Klärungszeilen für einen schnellen Gewinn beschnitten werden einige irreführende Lob von der Geschäftsführung.

Ich glaube, Sie sind schlau genug, dies zu erkennen, und das ist so ziemlich der Kern Ihrer ursprünglichen Frage. Das Problem ist nicht Ihr Verständnis, wann Code-Reduktion gut ist, und wenn es nicht gut ist, ist das Problem Dogmatismus bei der wahllosen Anwendung einer normalerweise vernünftigen Praxis.

Ich würde empfehlen, sich die Zeit zu nehmen, um mit Ihrem Management zu plaudern, Ihre Position zu erläutern und zu erklären, warum Sie das Gefühl haben, dass das, was Sie tun sollen, den Code eher schädigt als hilft. Versuchen Sie, Konfrontation zu vermeiden, aber versuchen Sie, während einer solchen Diskussion rational und ruhig zu bleiben. Es ist wichtig, dass Ihr Management versteht, dass das Programmieren eine pragmatische Aktivität ist. Ratschläge zu bewährten Verfahren sind nur dann nützlich, wenn sie pragmatisch angewendet werden. Best Practice wird in einem Buch geschrieben, das nicht in Stein gemeißelt ist. Wenn es zu Konflikten kommt (kurzer Code im Vergleich zu lesbarem Code), muss der Programmierer entscheiden, welche Best Practice zu befolgen ist. Hoffentlich sind es vernünftige Leute, die solche Beiträge zu schätzen wissen.

Sie müssen auch ein bisschen mutig sein, denn wenn Sie unter Druck gesetzt werden, den LOC dort zu reduzieren, wo Sie dies für unnötig oder unangemessen halten, ist es nur natürlich, dass Sie die Änderung trotzdem vornehmen, um ein ruhiges Leben zu führen. Sie müssen sich dagegen wehren und diese Entscheidung "besitzen". In einer Situation, in der das Management vernünftig ist, sollten Sie sich nicht genau an die Richtlinien halten müssen, aber Sie sollten in der Lage sein, alle Umstände zu rechtfertigen, in denen Sie dies nicht tun.

Leider können Menschen irrational sein, besonders wenn es um Menschen geht, die weniger in der Hackordnung sind und ihre Entscheidungen und die Regeln hinterfragen, die sie Ihnen auferlegt haben. Sie können sich dafür entscheiden, nicht vernünftig zu sein. Darauf müssen Sie auch vorbereitet sein. Wenn Sie Fälle demonstrieren können, in denen die Best Practice des LOC in direkten Konflikt mit anderen Best Practices gerät und warum dies dem Produkt schadet, und wenn Sie dies in Teilen der Codebasis tun können, für die sie keine oder nur eine geringe persönliche Beteiligung hatten (dies ist auch nicht der Fall) Dies scheint kein persönlicher Angriff auf ihre Arbeit oder die von ihnen beaufsichtigte Arbeit zu sein. Auch hier müssen Sie bereit sein, sich auf ruhige, rationale Weise zu rechtfertigen und die Argumente, die Sie vorbringen, "zu besitzen".

Vorausgesetzt, Ihr Management besteht aus vernünftigen Leuten, dann müssen sie zu schätzen wissen, dass das, was Sie sagen, einen Wert hat, wenn Sie Beweise für Ihre Behauptungen vorlegen können.

GordonM
quelle
2

Ich denke, Sie sollten sich in der Tat bemühen, Funktionen mit einer kleinen Anzahl von SLOC zu haben.

Wenn LOC (Codezeilen) eine kleine Zahl ist, wie wirkt es sich auf den Code aus, und wenn LOC eine größere Zahl ist, wie wirkt es sich auf den Code aus?

Idealerweise sollte es einfacher sein, 8 Codezeilen auf einen Blick zu verstehen, als 30.

Das bedeutet nicht, dass 30 LOC, die in 8 Zeilen komprimiert sind, einfacher zu verstehen sind.

Was denkst du, ist der richtige Weg, Dinge zu tun.

Normalerweise versuche ich in einer Funktion, sie nach Abstraktionsebenen zu gruppieren ("IO-Code hier", "Validierung hier", "Berechnung hier" usw.).

Dann habe ich es in Blöcke aufgeteilt, die durch eine Leerzeile getrennt sind. Wenn der Code mehr als zehn Zeilen umfasst, extrahiere ich jeden Block in eine andere Funktion (ich mache das sowieso für Code, der mehr als einmal vorkommt). Ich habe ein Argument darüber gehört, die Leistung auf diese Weise zu beeinträchtigen (unnötige Funktionsaufrufe), aber in der Praxis hatte ich nie einen Leistungsengpass, der dadurch verursacht wurde.

Das heißt, ich hatte Funktionen mit dieser Extraktion, und danach war die Funktion ~ 40 Zeilen lang (C-Code). Wenn der Code so gruppiert wie möglich ist, sehe ich kein Problem mit längeren Funktionen.

utnapistim
quelle
2

Ich denke, es ist wichtiger, sich auf sauberen, automatisch dokumentierten Code zu konzentrieren als auf LOC. Ihr Beispiel gefällt mir allerdings nicht wirklich, weil es erklärt, was der Code tut, ohne zu sagen, warum. Zum Beispiel das:

boolean sweet_sixteen = (age == 16);

ist ziemlich überflüssig. Jeder, der "Alter == 16" liest, weiß das. Ich würde den Code lieber so schreiben:

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

Die Logik zur Entscheidung, wann die Gruppe zu werfen ist, ist unabhängig vom System.out, kann getestet werden und ist leicht zu verstehen. Noch wichtiger ist jedoch, dass jemand, der den Code liest, den Grund dafür versteht, warum er so geschrieben wurde ("Unternehmen möchte für einige Leute eine große Party veranstalten").

Eduardo Scoz
quelle
2
Die Bedeutung des 16. Lebensjahres (und des 21. Lebensjahres) ist kulturspezifisch. Die Phrase "sweet sixteen" ist durchsuchbarer als "age == 16". Aus diesem Grund kann es nützlich sein, bestimmten Booleschen Werten Namen zu geben. Ich stimme jedoch Ihrer allgemeinen Meinung zu: Verschwenden Sie keine Zeit damit, sich selbst erklärenden Code zu erklären.
Jonas Kölker
1

Ich denke, weniger Codezeilen = besser lesbarer Code

Aber natürlich gibt es eine gewisse Grenze, wenn Sie anfangen, Ihren Code zu verkleinern / zu verdecken, nur um weniger Zeilen zu erhalten.

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

Dies ist eine Verkleinerung, die Logik bleibt gleich, nur weniger lesbar. Dies sollte nicht von Menschen gemacht werden, diese Verkleinerung wird von einer Maschine gemacht, um von einer Maschine gelesen zu werden.

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

Wenn Sie einen Teil des Codes entfernen können und der Algorithmus immer noch das tut, was er tun soll, fahren Sie fort. Minimieren Sie einfach Ihren Code nicht, dafür gibt es bessere Tools.

Vitim.us
quelle
1

Ich denke nicht, dass weniger Codezeilen besser lesbar sind. Die Realität, die sich stark von der Theorie unterscheidet, ist jedoch, dass der Code mit einer großen Anzahl von Zeilen häufig ohne ein geeignetes Design geschrieben wird. Infolgedessen kann die Forderung nach weniger Zeilen einige Programmierer zwingen, ein besseres Design zu entwickeln, wenn sie dazu in der Lage sind. Der Kniff ist, dass viele Programmierer nicht sind, dann hilft die Anforderung nicht viel.

zhouji
quelle
1

Ich würde die Anzahl der Zeilen unter normalen Umständen nicht als Problem ansehen, aber es kann auf Probleme hinweisen. Wenn Ihnen jemand eine Klasse mit 1000 Codezeilen zeigt, muss etwas mit der Art und Weise, wie die Klasse erstellt oder entworfen wurde, nicht stimmen.

Ihr Beispiel weist auf einen Fall hin, in dem eine größere Anzahl von Codezeilen sinnvoll ist. Aber das ist das Beispiel. Jeden Tag sehe ich Beispiele, bei denen die Anzahl der Zeilen auf mangelnde Planung zurückzuführen ist

IvoC
quelle
0

LOC ist zu Beginn eines Projekts eine viel nützlichere Metrik als während der tatsächlichen Implementierung, denke ich. Wenn Sie den LOC pro Funktionspunkt kennen, können Sie den Projektaufwand abschätzen und daraus ableiten, wie lange das Projekt dauern wird und wie viele Entwickler optimal sind.

Dies kann sich auch auf das Design und die Sprachauswahl auswirken: Das Reduzieren von Funktionspunkten oder das Wechseln zu einer Sprache mit niedrigerem LOC / FP sollte den Projektaufwand verringern, sofern alle anderen Faktoren gleich sind.

James Jensen
quelle
0

Codezeilen selbst sind nicht sehr wichtig. Eine Möglichkeit, es zu betrachten, besteht darin, es mit Prosa zu vergleichen. Die erste Erkenntnis ist, dass eine wichtige Eigenschaft sowohl des Codes als auch der Prosa (unter der Annahme der Korrektheit) die Lesbarkeit ist. Lesbarkeit (und Verständlichkeit) helfen bei anderen Eigenschaften wie Wartbarkeit und Korrektheit.

Es hat Vorteile, eine Funktion in eine kleine Anzahl von Zeilen einpassen zu können. Wenn Sie jedoch Text ohne Absätze haben, wird die Lesbarkeit beeinträchtigt. Die Verwendung schwieriger Konzepte, schwieriger (seltener) Wörter und komplexer Ausdrucksweisen verringert im Allgemeinen die Menge der Wörter, die zum Ausdrücken einer Idee benötigt werden, verschiebt jedoch gleichzeitig die Leseebene des Textes von der Sekundarstufe zu professionellen Akademikern (in der EU) Fall von Prosa).

Im Allgemeinen ist es hilfreich, Abstraktionen in Ihren Code einzufügen und Helfer usw. zu verwenden, aber auch diese Abstraktionen können zu zahlreich werden. Was auch passieren kann ist, dass die Komplexität in einen anderen Teil des Codes verlagert wird. Manchmal, wenn Sie als Experte ein Framework / eine Bibliothek zur Verwendung durch Junior-Programmierer (oder Studenten) entwerfen, ist dies eine gute Idee. Erwarten Sie jedoch nicht, dass die Junior-Benutzer einen Sinn für die Funktionsweise Ihres Codes haben, sondern machen Sie es ihnen nur sehr schwer, ihn falsch zu verwenden.

Scheuen Sie sich beim Schreiben von Code nicht, Leerzeilen in Ihren Code einzufügen. Sie fungieren als Absätze und helfen Ihnen, verschiedene Teile Ihrer Funktion zu trennen (auch wenn sie noch nicht in Helfern enthalten sein sollten).

Paul de Vrieze
quelle
-1

Das große Problem bei jeder formalen Methode zur Codebewertung ist, dass sie auf einem Code mit Sicherheit fehlschlägt. Dies liegt daran, dass die Programmierung eine Art Kunst ist und als solche keine klaren Standards für die Bewertung existieren können. Natürlich gibt es verschiedene Arten von Künsten - es gibt auch eine Massenproduktion von Gemälden, und vielleicht ist es in diesem Geschäft wichtig, wie viel Farbe für ein Gemälde ausgegeben wird. :)

Johnfound
quelle
-1

Um ganz ehrlich zu sein, kümmere ich mich nicht um die LOC-Messung. Sicher, es ist schön, dass eine Funktion oder Prozedur so kurz wie möglich ist, aber ich nehme lesbaren Code zu jeder Tageszeit zu kurz.

Vladimir Kocjancic
quelle
-2

Ich bin damit einverstanden, dass eine ständige Reduzierung des LOC zu einem schwer lesbaren Code führen würde.

Möglicherweise ist Ihr Codierungsstil jedoch zu ausführlich, und Ihr Reviewer ist der Meinung, dass eine präzisere Methode besser ist. Zum Beispiel ist ein Kommentar, der nur eine Aussage erklärt, die dank der klaren Wahl der Variablennamen ziemlich offensichtlich ist, nutzlos.

MatthieuW
quelle
5
Soweit mir bekannt ist, zählen Kommentare nicht zum LOC.
mhr
1
Je nach verwendeter Definition zählt es nicht oder nicht.
MatthieuW
1
Kommentare sind Kommentare. Sie sind kein Code. Daher gelten sie nicht für LOC-Zählungen. Selbstdokumentierender Code ist zwar besser als gut kommentierter Code, aber das Entfernen von Kommentaren aus weniger offensichtlichem Code ist für niemanden hilfreich.
GordonM
-2

Es gibt nur eine Sache, die Codezeilen messen, und das ist die Anzahl der Codezeilen, die Sie haben. Alles andere ist heiße Luft, Spekulation und Vorurteile.

Es gibt viele gute Beispiele in den anderen Antworten, wie weniger Codezeilen hat , kann etwas schlechter, nicht besser machen, aber ein Kernpunkt scheint zu übersehen wurden, und das ist: wie viele Zeilen tun Sie tatsächlich brauchen diesen Job zu tun ?

Wenn Sie für Ihre Aufgabe 10 Codezeilen benötigen, müssen Sie dies in 10 Zeilen tun. Wenn es 10.000 Zeilen braucht, dann tun Sie es auch in 10.000 Zeilen. Der Kult der „weniger Codezeilen“ wird nicht das letzte Beispiel macht besser , wenn Sie es in 1000 oder 2000 oder was auch immer zu tun. Der Job benötigte 10.000 Zeilen, und diese 10.000 Zeilen können Ebenen der Validierung, Fehlerprüfung, Sicherheit usw. enthalten, die Sie verpassen würden, wenn Sie dies in weniger Zeilen tun würden .

Bearbeiten

Da dies einige Ablehnungen hervorgerufen hat, denke ich, dass ich genauer sagen muss, was ich hier sage. Das erste, was jemand tun sollte, ist, dies zu lesen - der Punkt, den ich Sie bitten, ist, dass der Code auf hoher Ebene, den Sie schreiben, möglicherweise wenig oder gar keine Ähnlichkeit mit dem Maschinencode hat, der tatsächlich ausgeführt wird. Die Relevanz dieses Punktes besteht darin, dass ein Fokus auf Code auf hoher Ebene, ohne zu verstehen, was tatsächlich darunter vor sich geht, falsch ist.

Betrachten Sie nun Folgendes:

  • Es ist möglich, wirklich schlechten, langsamen Code mit nur einer einzigen Zeile zu schreiben - beachten Sie den Kommentar zum ternären Operator am Ende des von mir bereitgestellten Links.

  • Wenn eine Codezeile einen API-Aufruf (oder einen anderen Aufruf in eine externe Bibliothek) ausführt, haben Sie per Definition wenig Kontrolle darüber, was ausgeführt wird oder wie effizient es ist.

  • Fehlerprüfung, Reinigung, usw. alle fügen Sie zusätzliche Zeilen Code , und ich bin ganz sicher , dass selbst die eifrigsten Fan von weniger Codezeilen würden nicht gegen argumentieren diejenigen .

Codezeilen sind also eine gebrochene Metrik. Weniger Codezeilen garantieren keine zusätzliche Leistung - dieser API- oder Bibliotheksaufruf ist eine Zeile und kann außerhalb Ihrer Kontrolle liegen. Weniger Codezeilen garantieren keine zusätzliche Robustheit - Fehlerüberprüfung und Bereinigung erfordern immer zusätzliche Zeilen. Weniger Codezeilen garantieren nicht einmal zusätzliche Lesbarkeit oder Wartbarkeit - Sie müssen sich nur das IOCCC ansehen, um dies zu wissen.

Was garantieren weniger Codezeilen? Weniger Codezeilen, das ist alles.

Es ist zutiefst falsch, sich darauf zu konzentrieren, den gleichen Job in 2.000 Zeilen gegenüber 10.000 zu erledigen. Konzentrieren Sie sich stattdessen auf Code, der funktioniert, robust ist, innerhalb akzeptierter Toleranzen funktioniert und der einfacher zu lesen und zu warten ist. Manchmal bedeutet dies, dass Sie es mit einer niedrigen LoC-Anzahl tun können, manchmal bedeutet dies, dass Sie es mit einer höheren LoC-Anzahl tun müssen, aber die LoC-Anzahl sollte hier nicht wichtig sein.

mh01
quelle
1
Per Definition kann eine Aufgabe nicht in weniger als N Zeilen ausgeführt werden, wenn für die Ausführung N Codezeilen erforderlich sind (was an erster Stelle schwer zu bestimmen ist). Ihre Aufgabe mit 10.000 Zeilen kann also nicht in 2.000 Schritten erledigt werden. Ich denke, das OP spricht von den Fällen, in denen es einen gewissen Spielraum gibt, dh "die Anforderung kann in beiden Fällen vollständig erfüllt werden, also welche ist besser?"
Andres F.
-3

Wie wichtig ist es, die Anzahl der Codezeilen zu reduzieren? In den meisten Fällen überhaupt nicht. Tatsächlich ist es in den meisten Fällen wichtiger, die Anzahl der Codezeilen zu erhöhen, indem komplexe Vorgänge in besser lesbare Schritte unterteilt und jeder Schritt kommentiert sowie allgemein Kommentare hinzugefügt werden, um den Code für andere lesbarer und erweiterbarer zu machen Entwickler, die hinter dir her sind.

Infin8Loop
quelle
1
Warum all die Abstimmungen?
Marko
Ja, warum wurde eine vernünftige Antwort abgelehnt? Warum wurden andere vernünftige Antworten, die alle die Idee in Frage stellten, dass reduzierte Codezeilen ein Selbstzweck sind, ebenfalls abgelehnt?
Maximus Minimus
1
@ mh01 Ich vermute, weil das meiste davon falsch ist? Konkret in most cases, it is more important to increase the number of lines of code by breaking out complex operations into more readable stepsist das überhaupt nicht meine Erfahrung. Komplexer Code kann häufiger lesbarer und fehlerfreier gemacht werden, indem er kleiner und einfacher gestaltet wird, da er komplexer wird, weil er von jemandem geschrieben wird, der mit der Sprache noch nicht vertraut ist, nicht sicher ist, was er tut.
Izkata
-5

In früheren Perioden wurde angenommen, dass bei einer großen Anzahl von Codezeilen loc der Code effektiv ist und alle Aufgaben ausführt, für die er verwendet wird, aber nach einiger Zeit wurde erkannt, dass weniger ist, wenn loc mehr ist hat die Effizienz, da die Kosten, die dem System bei der Ausführung des Codes entstehen, sehr gering sind. Dadurch sollte die Verbesserung der Systemlok verringert werden. Seitdem wurde angenommen, dass die Lok geringer sein sollte. Um die folgenden Faktoren zu reduzieren sollte berücksichtigt werden.

  1. Machen Sie ein Flussdiagramm Ihres Problems
  2. Versuchen Sie, so wenig Schleifen wie möglich zu verwenden
  3. Die Funktionsaufrufe sollten nicht viel sein
  4. Neue Datenstrukturen wie TRIE sollten verwendet werden, wenn Stapel oder Warteschlange zum Speichern der relevanten Informationen verwendet werden.
  5. Und versuchen Sie, das Problem mit einem realistischen Ansatz zu lösen, anstatt mit einem einfallsreichen, bei dem Sie eine große Anzahl von Zahlen in einem sehr großen Array speichern und dann versuchen, über das Array darauf zuzugreifen.]
  6. Verwenden Sie so viele Makros wie möglich. Außerdem hängt der zu verwendende Ansatz auch vom Problem ab. Wenn er wirklich komplex ist, entspricht die Verwendung des einfachen Ansatzes manchmal auch dem komplexen Ansatz
Vibhu Tiwari
quelle
5
-1: Wow! Ich denke, Sie müssen den LOC in Ihrer Antwort reduzieren! Es tut meinen Augen weh, es zu lesen!
Jim G.
1
@JimG .: Ich stimme zu, dass die Antwort meine Augen verletzt, denke aber, dass dies am besten durch Erhöhen des LOC behoben werden kann (z. B. durch Verwenden einer separaten Zeile für jedes nummerierte Element).
Brian
Es war ein Fehler des Autoformatierers, der eine einzelne Leerzeile einfügte, bevor die Liste die Situation beseitigte
Balog Pal,