it-swarm-eu.dev

Wie wichtig ist es, die Anzahl der Zeilen im Code zu reduzieren?

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

Es geht nicht darum, redundanten Code zu entfernen, sondern 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 dies bedeutet, die Anzahl der Zeilen zu erhöhen.

Was denkst du ist die richtige Art, Dinge zu tun?
Wenn LOC (Codezeilen) 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.");
    }
}
86
Ankit

Das Problem bei Messungen, egal wie gut sie beabsichtigt sind, ist, dass das Messen des Gegenstands es wichtig macht, und die Konsequenz, dass das Nicht-Messen eines Gegenstands ihn unwichtig macht. Es ist absolut wichtig zu messen, was wichtig ist, und nicht zu messen, was unwichtig ist.

Das Messen des SLOC (was effektiv Ihre Bewertungen tun) macht SLOC wichtig ... Ist SLOC wichtig? - absolut nicht, war noch nie (Outside Obfuscated Programming Contests ), wird nie in einer kommerziellen Organisation sein.

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

75
mattnz

Ich stimme Ihren Codeprüfern zu, aber mit einem Sternchen. Jede Aussage, die Sie in Ihren Code schreiben, ist eine technische Haftung - ein potenzieller Fehlerpunkt. Wenn Sie eine Methode mit 10 Anweisungen schreiben und Ihr Mitarbeiter eine Methode schreibt, die mit 5 Anweisungen dieselbe Funktionalität erreicht, ist diese wahrscheinlich besser, gemessen an der Wahrscheinlichkeit von Problemen (es gibt doppelt so viele Stellen, an denen Ihr Code übermäßig falsch sein kann komplex oder problematisch).

Hier ist jedoch das Sternchen. Es geht nicht um die tatsächliche Anzahl von Codezeilen in der Idee, da Sie die Anzahl der Zeilen reduzieren können, indem Sie Folgendes tun:

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 also sagen, konzentrieren Sie sich darauf, mit den wenigsten Anweisungen das Beste zu tun - schreiben Sie so viel Code, wie Sie benötigen, um Dinge zu erledigen, und nicht mehr. Zumindest denke ich, dass Ihre Code-Reviewer genau das tun.

Persönlich denke ich, dass es ein Gleichgewicht gibt, das gefunden werden muss. Wie gesagt, jede Aussage, die Sie schreiben, ist eine Verpflichtung, aber wenn das Herausziehen einer lokalen Variablen mit einem beschreibenden Namen Ihre Methode viel klarer und lesbarer macht, dann gibt es auch dafür einen Fall. Ich denke, Sie können leicht in Situationen geraten, in denen Menschen über relativ kleine ästhetische Unterschiede streiten, aber im Großen und Ganzen haben Ihre Rezensenten die richtige Idee - bevorzugen Sie es, die Anzahl der Dinge zu minimieren, die schief gehen können.

85
Erik Dietrich

Den Rat der Rezensenten buchstäblich zu befolgen, bringt nichts, da das offensichtliche direkte Ergebnis darin besteht, knappe Einzeiler zu fördern (ungeachtet der Beschränkung der Zeilenlänge). Ich glaube jedoch, dass die Lektion, die hier gelernt werden muss, darin besteht, lassen Sie Ihren Code weniger tun.

Mit anderen Worten, dies ist ein Aufruf zur Einfachheit. Es ist eine weit verbreitete Behauptung, dass Code ist eine Verbindlichkeit, kein Vermögenswert , daher ist die Reduzierung des Betrags unter Beibehaltung der Funktionalität eine noble Sache Anstrengung. Dies kann durch einen direkten, bodenständigeren Ansatz erreicht werden, der das Problem direkt angeht und präzise Lösungen bevorzugt.

Wie Ken Thompson einmal sagte: Einer meiner produktivsten Tage war das Wegwerfen von 1000 Codezeilen .

32
Xion

Ich stimme Ihrer Position zu, "Klarheit im Code zu haben, auch wenn dies 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. Die Lesbarkeit ist entscheidend, da andere Entwickler Ihren Code pflegen müssen.

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

21
jhewlett

Ich arbeite derzeit als leitender Anwendungsentwickler und Projektgeschäftsanalyst für ein großes Unternehmen und war noch nie im Mittelpunkt meiner Entwicklung. Ich glaube jedoch, dass je komprimierter ein Code sein kann, desto besser, ABER nicht auf Kosten einer schnellen Analyse und Korrektur (oder Ergänzung). Für mich ist prägnanter, einfach zu lesender Code eines der wichtigsten Elemente in der Entwicklung, wenn Sie für geschäftskritische Anwendungen verantwortlich sind, die über ein hohes Maß an Skalierbarkeit verfügen und in einer sich ständig ändernden Umgebung Änderungen im laufenden Betrieb ermöglichen MÜSSEN . Zur Ehre von Erik Dietrichs Antwort , dies:

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, aber ich habe festgestellt, dass ich den gesamten vorhandenen Code des Unternehmens geändert habe von:

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

zu:

value.prop =  boolean ? option1 : option2;

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

Wie wirkt es sich auf den Code aus? Ich habe noch nie eine Leistungssteigerung oder -abnahme von beispielsweise 100 Codezeilen bemerkt. Eine einfache Tatsache ist, dass es mehr der Prozess ist, den Sie verwenden, um zum Endprodukt zu gelangen, als die Anzahl der Zeilen, 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 Codefluss.

12
Joshua Volearix

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

Nach meiner Erfahrung effektiver Code:

  • bricht keines der SOLID-Prinzipien
  • ist lesbar und selbsterklärend
  • besteht Albert Einsteins Einfachheitstest: "Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher."
9
Dino Octavian

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ätssoftware handelt. Darum geht es in dieser Frage nicht. Es geht darum, wie man mit Management umgeht, das auf einer naiven dogmatischen Einhaltung einer bestimmten Faustregel besteht.

Leider ist es ziemlich üblich, dass Menschen sich 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 verstehen, die der Rat überhaupt zu mildern hat .

Die Absicht von Ratschlägen, LOC niedrig zu halten, 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 Designs wissen, die nicht ihre sind direkte Verantwortung und von der alle anderen Klassen im System abhängig sind. Ein weiterer Vorteil von kürzerem Code besteht darin, dass er besser lesbar ist. Wie Sie bereits betont haben, können Sie ihn bis zu dem Punkt übertreiben, an dem die Lesbarkeit tatsächlich zu leiden beginnt.

Niedrige LOC-Zahlen haben offensichtliche Vorteile (kleine Methoden passen leichter in Ihren Kopf als große, weniger Dinge im Code bedeuten weniger Fehler usw.), aber sie unterliegen auch dem Gesetz der sinkenden Rendite. 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 einer anderen Facette eines guten Software-Designs (z. B. Lesbarkeit) geht, haben Sie einen Punkt erreicht, an dem Sie es rechtfertigen können, es nicht zu tun. Das Entfernen von Variablen, die den Kontext der Bedeutung des Codes angeben, und das Ersetzen durch Literale, die dies nicht tun, ist eine sehr, sehr schlechte Sache. Guter Code enthält fast keine Literale. Diese Variablen (und benannten Konstanten) sind jedoch Codezeilen, die nicht direkt zum Programm beitragen. 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 ein fehlgeleitetes Lob vom Management.

Ich glaube, Sie sind klug genug, um dies zu realisieren. Tatsächlich ist das so ziemlich der Kern Ihrer ursprünglichen Frage. Das Problem ist nicht Ihr Verständnis dafür, wann die Code-Reduzierung gut ist und wann nicht, das Problem ist Dogmatismus bei der wahllosen Anwendung einer normalerweise vernünftigen Praxis.

Ich würde empfehlen, sich die Zeit zu nehmen, um mit Ihrem Management zu chatten, Ihre Position zu erläutern und zu erklären, warum das, was Sie tun sollen, dem Code eher schadet als hilft. Versuchen Sie zu vermeiden, konfrontativ zu sein, aber versuchen Sie, während einer solchen Diskussion rational und ruhig zu bleiben. Es ist wichtig, dass Ihr Management versteht, dass Programmierung eine pragmatische Aktivität ist, und Best-Practice-Ratschläge 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 (Kurzcode versus lesbarer Code), muss der Programmierer beurteilen, welche Best Practice zu befolgen ist. Hoffentlich sind sie vernünftige Leute, die solche Beiträge schätzen.

Sie müssen auch ein bisschen mutig sein, denn wenn Sie unter Druck gesetzt werden, den LOC zu reduzieren, wenn 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, unter denen Sie dies nicht tun.

Leider können Menschen irrational sein, insbesondere wenn es um Menschen geht, die weniger Hackordnung haben und ihre Entscheidungen und die Regeln, die sie Ihnen auferlegt haben, in Frage stellen. Sie können sich dafür entscheiden, nicht vernünftig zu sein. Darauf müssen Sie auch vorbereitet sein. Wenn Sie Fälle aufzeigen können, in denen die LOC-Best Practice in direkten Konflikt mit anderen Best Practice gerät und warum dies das Produkt schädigt, und wenn Sie dies in Teilen der Codebasis tun können, für die sie nur wenig oder gar keine persönliche Beteiligung hatten (so ist dies nicht der Fall) Dies scheint kein persönlicher Angriff auf ihre Arbeit oder die von ihnen beaufsichtigte Arbeit zu sein. Dann kann dies Ihre Argumentation unterstützen. Auch hier müssen Sie bereit sein, sich auf ruhige, rationale Weise zu rechtfertigen und in der Lage zu sein, die von Ihnen vorgebrachten Argumente zu "besitzen".

Vorausgesetzt, Ihr Management besteht aus vernünftigen Personen, muss es anerkennen, dass das, was Sie sagen, von Nutzen ist, wenn Sie Beweise für Ihre Behauptungen vorlegen können.

6
GordonM

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, leichter zu verstehen sind.

Was denkst du ist die richtige Art, Dinge zu tun?.

Normalerweise versuche ich in einer Funktion, sie nach Abstraktionsebenen zu gruppieren ("E/A-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 (das mache ich sowieso für Code, der mehr als einmal vorkommt). Ich habe ein Argument über eine Leistungsunterbrechung auf diese Weise gehört (unnötige Funktionsaufrufe), aber in der Praxis hatte ich nie einen dadurch verursachten Leistungsengpass.

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

2
utnapistim

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

boolean sweet_sixteen = (Alter == 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 Party geworfen werden soll, ist von System.out getrennt, kann getestet werden und ist leicht zu verstehen. Noch wichtiger ist jedoch, dass jemand, der den Code liest, den Grund verstehen kann, warum er so geschrieben wurde ("Unternehmen möchte für einige der Leute eine große Party veranstalten").

2
Eduardo Scoz

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 mit mangelnder Planung zusammenhängt

1
IvoC

Ich denke, weniger Codezeilen = besser lesbarer Code

Aber natürlich gibt es einige Grenzen, wenn Sie anfangen, Ihren Code zu minimieren/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 Minimierung, die Logik bleibt gleich, nur weniger lesbar. Dies sollte nicht von Menschen gemacht werden, diese Minimierung 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 Ihren Code einfach nicht, es gibt bessere Tools dafür.

1
Vitim.us

Ich denke nicht, dass weniger Codezeilen == besser lesbarer Code 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. Folglich kann das Erfordernis weniger Zeilen einige Programmierer dazu zwingen, ein besseres Design zu entwickeln, wenn sie dazu in der Lage sind. Die Wendung ist, dass viele Programmierer nicht sind, dann hilft die Anforderung nicht viel.

1
zhouji

LOC ist eine viel nützlichere Metrik zu Beginn eines Projekts als während der tatsächlichen Implementierung, denke ich. Wenn Sie das 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 auch das Design und die Sprachauswahl beeinflussen: Das Reduzieren von Funktionspunkten oder das Wechseln zu einer Sprache mit einem niedrigeren LOC/FP sollte den Projektaufwand reduzieren, wenn alle anderen Faktoren gleich sind.

0
James Jensen

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 von Code und Prosa (unter der Annahme der Korrektheit) die Lesbarkeit ist. Die Lesbarkeit (und Verständlichkeit) hilft bei anderen Eigenschaften wie Wartbarkeit und Korrektheit.

Es hat Vorteile, eine Funktion in eine kleine Anzahl von Zeilen einpassen zu können. Text ohne Absätze verringert jedoch die Lesbarkeit. Durch die Verwendung schwieriger Konzepte, schwieriger (seltener) Wörter und komplexer Ausdrucksweisen wird im Allgemeinen die Anzahl der zum Ausdruck einer Idee erforderlichen Wörter verringert, gleichzeitig wird jedoch die Lesestufe des Textes von der Sekundarstufe bis zu professionellen Akademikern (in der 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 auf einen anderen Teil des Codes verschoben wird. Manchmal, beispielsweise wenn Sie als Experte ein Framework/eine Bibliothek für Junior-Programmierer (oder Studenten) entwerfen, ist es eine gute Idee, dies zu tun. Erwarten Sie jedoch nicht, dass die Junioren verstehen, wie Ihr Code funktioniert. Machen Sie es ihnen nur sehr schwer, ihn falsch zu verwenden.

Scheuen Sie sich insbesondere beim Schreiben von Code nicht, leere Zeilen 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 Helfer eingefügt werden sollten).

0
Paul de Vrieze