Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Moin, kurz zu meinem bisherigen Wissensstand, damit diese Frage nicht kurzerhand wieder als Troll nach einigen Antworten aufgefasst wird: Ich bin 15pkt Info LK`ler und möchte gerne wissen, wann ihr eine große Funktion / einen Ablauf in mehrer Kleine unterteilt.
Beispiel: Dijkstra Algorithmus - mit Sicherheit in einer Funktion locker runterprogrammierbar, aber ist es nicht klüger mehrere kleine Methoden zu erstellen wie update Queue oder so? Und wie sieht es da mit der Laufzeit aus? Wie steht ihr dazu?
Bei static Funktionen ist es ja klar, dass eigentlich stellvertretend (hardcoded) für die Funktion dort der Quelltext kompiliert wird. Aber für Methoden instanziierter Objekte?
Das hat nichts mit seinem Geschlecht zu tun. Er wollte dir damit mitteilen, dass er in der Oberstufe einen Informatik-Leistungskurs besucht und dort 15 Punkte (Note 1+) hat
Ich wollte das an für sich etwas anders schreiben. Sobald es möglich ist, sollte man Code aufteilen.... in sinnvolle, kleinere, logische Einheiten....
Und zu der 1+, das bedeutet wohl nicht viel, bei der heutigen Einsen Inflation=Schwämme... Vor 30 Jahren hatte ein Gymnasium einen Schüler mit 1.0 heute sind es schon 10. Außerdem ist dein Verhalten nicht völlig alturistisch find ich. Wenn man etwas besser kann als der Schnitt dann sollte man das den anderen nicht so um die Ohren hauen.
Nunja - die Anforderungen an einen Informatik Leistungskurs können doch nicht höher sein als die Anforderung an Informatik Studenten, oder? und ich denke, da haben wir hier doch schon einiges erlebt
Und wann eine große Funktion unterteilt wird mit immer zu antworten ist irgendwie sinnlos. So lange wie "groß" nicht definiert ist, ist die Aussage absoluter Quatsch und hilft auch nicht weiter.
Angenommen, wie haben einen Codingstandard, der vorgibt, dass Funktionen nicht länger als x Zeilen lang sein darf (habe ich aber so noch nie erlebt!): Dann gibt es nach diesem Codingstandard kleine Funktionen (z.B. weniger als x/2 Zeilen) und große Funktionen (x/2 - x Codezeilen). Und natürlich gibt es dann keinen zwingenden Grund, die "großen Funktionen" zu unterteilen. Und wenn man das hätte, dann hätte man ja einen neuen Codingstandard, der vorgibt, dass Funktionen nicht länger als x/2 Zeilen lang sein dürften. Dann würde man aber als große Funktionen eben plötzlich die Funktionen mit mehr als x/4 Zeilen ansehen ....
Also klare Definitionen sind hier notwendig. Und es kann immer Ausnahmen geben. Wer weiss: Evtl. gibt es tatsächlich einen Fall, in dem es Sinn macht, dass man einfach mal eine Funktion etwas länger werden lässt. Wenn ich z.B. eine switch Anweisung nehme mit einigen case Zeilen. (Ist halt ein Enum mit 20 Elementen oder 30 Elementen!) Dann kann das durchaus Sinn machen, die Funktion eben genau so zu lassen.
Es geht halt nur teilweise um die Größe. Eine Funktion sollte in erster Line eine Sache machen (@Javinner hat das ja schon sehr gut geschrieben) rund alles was sie macht sollte auf einem Level sein. (Also wenn du da eher high level Aufrufe hast, dann sollte da nicht plötzlich noch irgendwas Low Level mäßiges gemacht werden.)
Und ganz wichtig sind die Namen: Ein Code sollte ohne Kommentare direkt gut lesbar sein!
Und meine Meinung ist, dass man sich Refactorings einfach einmal ansehen sollte am Anfang. Das Bedeutet:
- Beschäftige Dich damit, wie man sinnvoll etwas umstellen kann. Da gibt es generell gute Bücher. Such mal nach Clean Code und so. Aber auch https://clean-code-developer.de/ fand ich damals mal sehr gut... (Da geht es um deutlich mehr. Aber das ganze Thema muss behandelt werden.)
- Dann mach es einfach. Und dann vergleich die Resultate: Was ist besser lesbar? So bekommst Du zum einen Übung in Refactorings und zum anderen hast Du dann Erfahrung, was besser lesbar ist.
So nur als Anekdote aus meinem Berufsleben:
Als in .Net dann Lambda Ausdrücke erlaubt wurden, hat die IDE teilweise angeboten, Dinge direkt in kurze Lambda Ausdrücke zu vereinfachen. Da haben wir dann immer gesagt: mach mal. Dann geschaut: War das noch intuitiv? Wenn ja: Ok, ansonsten rückgängig machen.
Code muss ja gewartet werden können, Team Mitglieder sollen es lesen und verstehen können ohne groß Zeit investieren zu müssen. So musste also der Code geschrieben werden.
Und das erklärt dann evtl. einiges. Du bist also noch Schüler in einem Informatik LK mit weniger Lebensjahren als einige hier (Zumindest ich) Jahre an Berufserfahrung im Bereich Software Engineering haben....
Ach ja: Evtl. gibt es ja mehrere im Leistungskurs, die gut sind:
Wie wäre es mit gemeinsamen Code Reviews? Das haben wir zumindest damals in meiner Oberstufe so gemacht. Dann kann man auch drüber reden, was wer besser findet und aus welchem Grund. Das kann bestimmt auch helfen. (Und ist auch der Weg, wie ich es im Berufsleben kennen gelernt habe wenn es darum ging, andere mit einzubinden in ein Team bzw. als Team die Coding Styles festzulegen, denn die sind ja teilweise immer flexibel ...)
@kneitzel Das immer bezog sich nicht auf die Größe zu langer Methoden, sondern eine Definition dafür habe ich schon angegeben.
Um eine Bewertung meiner Erfahrungen habe ich nicht gebeten. Ich finde es aber gut, dass ihr das Augenmerk auf pair programming, collaboration und refactoring legt. Das machen Autohersteller ja auch und es läuft bestimmt auch nicht schlecht.
Und wann eine große Funktion unterteilt wird mit immer zu antworten ist irgendwie sinnlos. So lange wie "groß" nicht definiert ist, ist die Aussage absoluter Quatsch und hilft auch nicht weiter.
Ich finde, es ist schon der Hinweis, der am Anfang angebracht ist. Die meisten Anfänger neigen ohnehin dazu, viel zu große Funktionen zu schreiben. Natürlich könnte man voraus schicken, dass in solchen Aussagen "immer" immer "immer, bis auf gut begründete Ausnahmen" bedeutet. Das war mir aber zu umständlich. Ich würde "immer" als Grundregel so stehen lassen.
Auch die Definition von "groß" ist nicht unbedingt nötig. Wenn man auf die Idee kommen kann, eine Funktion groß zu nennen, ist sie (immer, bis auf gut begründete Ausnahmen) tatsächlich zu groß. Wenn man aufgrund von Richtlinien ohnehin nur von bereits größengrenzten Funktionen spricht, ist das ein anderer Kontext, in dem "groß" natürlich eine andere Bedeutung bekommt. Aber bisher wurde das ja noch ganz allgemein diskutiert. Unter'm Strich geht es mir nur darum, ohne wenn und aber für kleine Funktionen zu plädieren. Wenn man da zu viel rumdefiniert, gerät die Kernaussage schnell unter die Räder.
Wenn ich z.B. eine switch Anweisung nehme mit einigen case Zeilen. (Ist halt ein Enum mit 20 Elementen oder 30 Elementen!) Dann kann das durchaus Sinn machen, die Funktion eben genau so zu lassen.
Und meine Meinung ist, dass man sich Refactorings einfach einmal ansehen sollte am Anfang. Das Bedeutet:
- Beschäftige Dich damit, wie man sinnvoll etwas umstellen kann. Da gibt es generell gute Bücher. Such mal nach Clean Code und so.
In meiner Ausgabe von Clean Code (deutsche Version, 1. Auflage von 2009) beginnt das Kapitel über Funktionen übrigens mit dem Abschnitt 3.1. Dessen Überschrift lautet "Klein!".
Und aus diesem Abschnitt:
"Functions should hardly ever be 20 lines long." und "Every function in this program was just two, three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That's how short your functions should be!"
Wobei ich zu lange Zeilen eigentlich schlimmer finde als zu lange Methoden.... bis auf gut begründete Ausnahmen sehe ich bei zu langen Zeilen rar. Aber ich schreibe auch noch keine Coding Styles, denn so viel Erfahrung habe ich doch nicht.
Ich finde es viel schlimmer wenn eine Methode die eigentlich nur eine Sache macht und die auch nirgendwo anders gebraucht wird in 10 kleine Methoden unterteilt wird und ich dann die ganze Zeit hin und herspringen muss um zu verstehen was eigentlich gemacht werden soll.
Eine Unterteilung einer Methode in mehrere kleinere macht nur dann Sinn, wenn aus dem Namen de kleinen Methoden zu 100% hervorgeht was sie tut und das ist in 99% der Fälle verdammt schwierig einen so guten Namen zu finden den eben auch alle verstehen.
Wenn eine Methode mal 200 Zeilen lang ist dann ist das auch kein Problem solange sie nicht aus tausend verschachtelten schleifen besteht sondern einfach hintereinander weg seine Aufgabe erledigt. Dann ist auch so eine lange Methode einfach zu lesen. Für mich sogar einfacher..-
Ich finde es viel schlimmer wenn eine Methode die eigentlich nur eine Sache macht und die auch nirgendwo anders gebraucht wird in 10 kleine Methoden unterteilt wird und ich dann die ganze Zeit hin und herspringen muss um zu verstehen was eigentlich gemacht werden soll.
Eine Unterteilung einer Methode in mehrere kleinere macht nur dann Sinn, wenn aus dem Namen de kleinen Methoden zu 100% hervorgeht was sie tut und das ist in 99% der Fälle verdammt schwierig einen so guten Namen zu finden den eben auch alle verstehen.
Wenn eine Methode mal 200 Zeilen lang ist dann ist das auch kein Problem solange sie nicht aus tausend verschachtelten schleifen besteht sondern einfach hintereinander weg seine Aufgabe erledigt. Dann ist auch so eine lange Methode einfach zu lesen. Für mich sogar einfacher..-
Ja, ich denke, dass dies ähnlich ist wie bei der Normalisierung von Datenbanken. So weit wie notwendig ist auf jeden Fall gut, aber man sollte nicht zu sehr übertreiben.
Und es muss wirklich intuitiv verstehbar sein. Die 20 Zeilen, die mal genannt wurden, überschreiten wir bei unserer Entwicklung aber auch durchaus öfters ohne dass wir da dann irgendwelche Ausnahmen begründen würden ... Und wenn ich dann lese 2, 3 oder 4 Zeilen - Das trifft die Realität zumindest soweit ich diese gesehen habe, nicht.
Aber ja, dass es technisch geht, ist klar. Aber das würde ich so nie als Ziel ansehen. Es geht wirklich darum, dass man einen gut lesbaren Code hat.
Aber 200 Zeilen halte ich für extrem und da kann ich mir im Augenblick nicht vorstellen, dass dies lesbar ist. Ich will eine Funktion auf einen Blick überblicken können und das geht nur bis 20-30 Zeilen - danach passt es ggf. nicht mehr auf den Bildschirm (Wenn man Debugger und co auf hat, wird das Code-Fenster doch relativ klein... Selbst bei großen Bildschirmen.)
Und es muss wirklich intuitiv verstehbar sein. Die 20 Zeilen, die mal genannt wurden, überschreiten wir bei unserer Entwicklung aber auch durchaus öfters ohne dass wir da dann irgendwelche Ausnahmen begründen würden ... Und wenn ich dann lese 2, 3 oder 4 Zeilen - Das trifft die Realität zumindest soweit ich diese gesehen habe, nicht.
Aber ja, dass es technisch geht, ist klar. Aber das würde ich so nie als Ziel ansehen. Es geht wirklich darum, dass man einen gut lesbaren Code hat.
Aber 200 Zeilen halte ich für extrem und da kann ich mir im Augenblick nicht vorstellen, dass dies lesbar ist. Ich will eine Funktion auf einen Blick überblicken können und das geht nur bis 20-30 Zeilen - danach passt es ggf. nicht mehr auf den Bildschirm (Wenn man Debugger und co auf hat, wird das Code-Fenster doch relativ klein... Selbst bei großen Bildschirmen.)
Methoden länger als 20 Zeichen Zeilen werfen in meinem aktuellem Projekt eine (Checkstyle-) Warnung. Bisher jedes Mal, wenn es mehr waren, war das eine berechtigte Warnung mit ziemlich hässlicher Code, der nach einem Refactoring deutlich besser aussah. Aktuell überlege ich, die 20 Zeichen Zeilen als harte Grenze einzuführen, und bei überschreiten einen Fehler werfen zu lassen...
4 Zeilen als Maximum sind hart, das ist grad mal ein if plus eine weitere Zeile oder ein einzelner sinnvoll umgebrochener Stream-Aufruf. ~7 würde ich zumindest in meinem aktuellem Projekt als gut und sinnvoll machbar einschätzen, der Großteil der Methoden (abseits von Gettern/Settern) liegt sowieso schon in dem Rahmen.
200 sind aber wirklich Horror, aktuell gibts bei uns nicht mal Klassen, die so lang sind (okay, ein paar wenige sind, aber die liegen nur wegen den 30 Zeilen Header darüber...) Wer mit sowas arbeiten muss, dem seien Clean Code von Martin und Refactoring von Fowler ans Herz gelegt...
Auch 200 Zeilen können sinnvoll sein wenn man sie als logische Einheiten auffasst - ohne nicht unnötigerweise hin und her scrollen zu müssen. @Meniskusschaden hat recht, das sind gut begründete Ausnahmen wobei das "begründete" hier nicht verlauten soll, auch nur irgendeine "zu lange" Methode nur der check styles wegen genauer begründen zu müssen.
Eher sind die einzusetzenden check styles zu begründen - möchte man nicht dass ich diese einfach ignorierend übergehe....
Ok, die 20 Zeilen waren bei mir incl. "non code" Zeilen. Also die eine oder andere Leerzeile, ggf { } oder auch mal ein Kommentar.
Wenn man Funktionen hat, die auch als API dienen, dann hat man ja auch zuerst noch eine Validierung der Argumente. Und das sind dann 1 Kommentar (ok, den mag man weglassen wollen, derzeit setzen wir den) und pro Argument meist eine kurze Zeile mit nachfolgender Leerzeile. Ich nenne non code Zeilen, denn die sind beim 20-30 Zeilen Limit bei uns mit drin.
(Das ist dann etwas, das mir bei Kotlin gut gefallen hat. Da sind null Checks direkt entfallen, da dann Argument schon direkt kein null annehmen konnten)
Die Bücher kann ich aber auch sehr empfehlen. Man kann sich hinter her immer noch überlegen, was wie viel Sinn macht. Aber erst einmal sollte man alles kennen lernen. (Ein Beispiel wären z.B. Kommentare, denn da gibt es diverse Ansichten. In dem Clean Code Buch war - so ich mich jetzt in den Büchern nicht vertue - die klare Aussage, dass Kommentare sogar etwas böses sind....)
Ich müsste nachgucken, aber soweit ich weiß werden nur Leerzeilen und Kommentare ignoriert, Blöcke werden als Code gezählt.
Inline-Kommentare kommen sowieso kaum vor (ich sollte dran denken, die mal eine Warnung werfen zu lassen ) und leerzeilen erhöhen ja oft sehr die Lesbarkeit, und solange sie sinnvoll sind, sind das dann vielleicht 25 statt 20 Zeilen.
Wenn man Funktionen hat, die auch als API dienen, dann hat man ja auch zuerst noch eine Validierung der Argumente. Und das sind dann 1 Kommentar (ok, den mag man weglassen wollen, derzeit setzen wir den) und pro Argument meist eine kurze Zeile mit nachfolgender Leerzeile. Ich nenne non code Zeilen, denn die sind beim 20-30 Zeilen Limit bei uns mit drin.
(Das ist dann etwas, das mir bei Kotlin gut gefallen hat. Da sind null Checks direkt entfallen, da dann Argument schon direkt kein null annehmen konnten)
Naja, der Kommentar steht bei mir in der Doku, die Validierung ist meist ausgelagert soweit möglich, und wäre sowieso kaum länger als eine Zeile, alle zusammen sind vielleicht 4, 5 Zeilen, mehr Parameter werden schnell unübersichtlich.
Kotlin hat dabei nur das Problem, wenn es mit Javacode und Reflection benutzt wird, dann ist sowas plötzlich doch null
Die Bücher kann ich aber auch sehr empfehlen. Man kann sich hinter her immer noch überlegen, was wie viel Sinn macht. Aber erst einmal sollte man alles kennen lernen. (Ein Beispiel wären z.B. Kommentare, denn da gibt es diverse Ansichten. In dem Clean Code Buch war - so ich mich jetzt in den Büchern nicht vertue - die klare Aussage, dass Kommentare sogar etwas böses sind....)
Die Kritikpunkte an Kommentaren teile ich größtenteils.
Meist sind die Kommentare völlig unnütz (if (i == 1)//ob i gleich 1 ist), dann gehen sie beim nächsten Refactoring kaputt (if (i >= 1)//ob i gleich 1 ist) und wenn sie doch mal nützlich sind, sind sie besser als Methodenname aufgehoben (if (b != null && b.i == 1 && b.xyz() || b.zyx())//validate b). Der Anfänger-Bereich hier ist oft und wunderbares Beispiel dafür...
Auch 200 Zeilen können sinnvoll sein wenn man sie als logische Einheiten auffasst - ohne nicht unnötigerweise hin und her scrollen zu müssen. @Meniskusschaden hat recht, das sind gut begründete Ausnahmen wobei das "begründete" hier nicht verlauten soll, auch nur irgendeine "zu lange" Methode nur der check styles wegen genauer begründen zu müssen.
Eher sind die einzusetzenden check styles zu begründen - möchte man nicht dass ich diese einfach ignorierend übergehe....
Das Sinn oder Unsinn machen wir halt klar an der Lesbarkeit / Verständlichkeit ab. Die "Regeln" geben nur Hinweise. Entscheidend ist das Code Review, und da ist es dann aber tatsächlich so, das Abweichungen erläutert werden.
Aus dem Grund wird oft mal etwas umgeschrieben, ob wohl es nicht zwingend notwendig ist, denn in diesem Fall mit den langen Funktionen ist es ebenso schnell da eine oder mehrere Funktionen zu erstellen wie später dazu etwas zu sagen.
Eine 200 Zeilen Funktion kann ich mir nicht vorstellen. Ich kann mir auch im Augenblick keinen Extremfall vorstellen, bei dem das notwendig sein könnte. Die etwas längere Funktion z.B. auf Grund einer switch Anweisung (Switch hat ohne case in java 2 Zeilen) und pro case kommen dann 1. case, 2. Befehl / Aufruf 3. break;. 4. Leerzeile -> 4 Zeilen dazu. Ok, Wenn man nur Code Zeilen zählt, dann wird die Leerzeile und die } nicht gezählt, aber man erkennt, dass es hier schwer ist, etwas zu machen.
Und klar: Man kann vieles in eine Zeile schreiben: "case x: doSomething(); break;" aber Ziel ist die Lesbarkeit und da wollen wir nur einen Befehl pro Zeile. (Typische Ausnahme wäre die Validierung, denn da haben wir dasganze if inc. throw Anweisung in einer Zeile.)
Ebenso sollte ja auch eine Zeile nicht zu lang sein. Daher auch oft die Auftrennung in mehrere Zeilen wenn man so typische Builder Aufrufketten hat. Typisches Beispiel, das mir da einfällt, wäre bei der Spring Security:
Java:
UserDetails user =
User.withDefaultPasswordEncoder()
.username("user")
.password("password")
.roles("USER")
.build();
Also das oberste Ziel ist immer die Lesbarkeit. Es geht hier nicht darum, Funktionen auf Zwang klein zu bekommen.
(Das erinnert mich an einen Perl Entwickler, den ich mal kennen gelernt habe. Die Kunst ein Perl Script in < 5 Zeilen zu schreiben. Eine Zeile ist ja in der Länge auch nicht begrenzt )
Die Kritikpunkte an Kommentaren teile ich größtenteils.
Meist sind die Kommentare völlig unnütz (if (i == 1)//ob i gleich 1 ist), dann gehen sie beim nächsten Refactoring kaputt (if (i >= 1)//ob i gleich 1 ist) und wenn sie doch mal nützlich sind, sind sie besser als Methodenname aufgehoben (if (b != null && b.i == 1 && b.xyz() || b.zyx())//validate b). Der Anfänger-Bereich hier ist oft und wunderbares Beispiel dafür...
Ja, also erst zu dem, was ich rausgelöscht habe: Die Dokumentation der API Schnittstelle (JavaDoc und co) zählt hier nicht als Kommentar, der den Code selbst erläutert sondern das ist ja mehr die Erstellung einer Dokumentation.
Und In Code Kommentare dürfen nicht wiedergeben, was der Code macht (das sieht man ja am Code) sondern es muss klar sagen, wieso das notwendig ist. Wenn also irgend etwas sich anders verhält als erwartet (weil die Dokumentation falsch oder unklar war): Da macht ein Kommentar auf jeden Fall Sinn und rechtfertigt manchmal sogar noch einen extra Abschnitt in der Dokumentation. Aber ich gebe Dir durchaus Recht: Der Kommentar // validating Arguments macht nicht wirklich Sinn, wenn dann klar ersichtlich ein Block kommt mit Validierungsbefehlen.... Damit habe ich sogar ein super Beispiel für Dich gebracht bezüglich: Ist doch eigentlich unnötig.
Ist aber auch wieder ein Zeichen dafür, dass hier vieles eben Absprache in einem Team ist. Das Team muss wissen, was es erwartet.
Fängt ja schon mit der Namensgebung an. Wie schreibe ich was? Für APIs gibt es oft styling guides. Da sind sich dann meist alle einig. Wobei ein Team, das in erster Linie C++ entwickelt, evtl. doch noch Kürzel für Typen haben will bei Variablen und Funktionen (Wäre ja legitim. Die sind es halt so gewohnt. Für die wird der Code so lesbarer sein.)
Aber typische Frage bei .Net war z.B. private Instanzvariablen. Da die nicht sichtbar sind nach außen, hat Microsoft hier nichts vorgegeben. Bei uns sind solche Fields (.Net Name für eine Instanzvariable) dann immer mit _ und kleingeschrieben. Der typische Java Code mit Getter / Setter wäre in .Net dann:
Code:
private int _someVariable;
public int GetSomeVatiable()
{
return _someVariable;
}
public void SetSomeVariable(int someVariable)
{
_someVariable = someVariable;
}
// Natürlich macht das so niemand. .Net hat Properties:
public int someProperty { get; set; }
Aber üblich ist auch z.B. der Prefix m_. Manche machen es auch ganz ohne Prefix.
Also mal von unterschiedlicher Schreibweise (Methoden sind PascalCase und nicht camelCase) erkennt man auch, dass hier keine Instanzvariable von einem Argument versteckt wird. Also kein this.someVariable = someVariable; was ich immer in Java schrecklich finde. (Setzt ihr eigentlich Lombok ein um das Thema Getter/Setter/hashCode/equals abzufrühstücken?)
Also man kann hier wirklich sehr viel schreiben. Interessant ist, dass es nicht wirklich ein "Richtig" oder "Falsch" gibt. Es gibt aber sehr wohl Anforderungen. Das kann in Schule / Studium der Lehrer/Dozent/Professor sein, der es halt auf eine bestimmte Art haben will und um Job ist es dann ggf. das Team. (Oder so man Einzelkämpfer ist, dann man selbst. Aber man sollte da durchaus auch selbst Wert drauf legen, wenn es keinen Zwang von außen gibt )
Soviel einfach noch einmal von meiner Seite aus...
Das sehe ich etwas anders: ist gibt keine in Zeilen messbare, harte Grenze. Falsch und richtig entscheidet sich an der Lesbarkeit. Und lesbar heißt: ein Blick und ich muss wissen, was das Ding macht.
Was die Kommentare betrifft, ist das in meinen Augen ein guter Indikator, der sich auch unerfahrenen Leuten gut vermitteln lässt. Wenn man sie fragt, warum sie sich die Arbeit machen, toten Text in den Quelltext einzufügen, dann geht ihnen sehr schnell ein Licht auf.
Dabei stoße ich immer wieder auf Kommentare folgender Kategorien:
1. Sinnfreie Kommentare. Das sind insbesondere solche, die in natürlicher Sprache exakt das beschreiben, was in der Zeile bzw. der darauf folgenden Zeile steht.
Java:
// wenn Liste leer
if (list.isEmpty()) {
2. Kommentare zur Erklärung (komplexer) Bedingungen. Das ist oft ähnlich zum vorherigen Punkt, allerdings ist die Bedingung nicht auf den ersten Blick offensichtlich
Java:
// wenn Rechteck den Punkt enthält
if (p.x >= r.x1 && p.y >= r.y1 && p.x <= r.x2 && p.y <= r.y2) {
...
}
3. Kommentare zur Strukturierung von Code
Java:
// Schritt 1: blabla
x Zeilen Code
// Schritt 2: blabla
x Zeilen Code
...
// Schritt n: blabla
x Zeilen Code
Noch "schöner" ist es, wenn manche dann nicht einfache Zeilenkommentare einfügen sondern komplette Blöcke:
Kommentare der 1. Kategorie sind natürlich einfach zu entfernen. Die anderen beiden schreien nach Methoden.
Den Leuten kann man sagen: bevor Du hergehst und schreibst irgendeinen Kommentar rein, mit dem weder der Compiler noch die IDE was anfangen kann, formulier den Kommentar einfach als Methode. Die kannst Du, wenn es ist, mehrfach verwenden (DRY), außerdem hast Du IDE Unterstützung (Refactoring, Code Completion), aber vor allem wird Dein Code sprechend.
Aus 2. wird dann z. B. zunächst
Java:
if (r.contains(p)) {
...
}
und weil das jetzt so schön kurz ist, kann man auch gerne sprechende Variablennamen verwenden, die vorher vermieden wurden, weil die Bedingung sonst noch länger geworden wäre...
und weil das jetzt so schön kurz ist, kann man auch gerne sprechende Variablennamen verwenden, die vorher vermieden wurden, weil die Bedingung sonst noch länger geworden wäre...
So und nun komme ich daher und weiß nicht ob das contains bedeutet das der Punkt auch auf dem Border liegen darf oder ob er wirklich innerhalb des Rahmens sein muss.... Also muss ich mir doch wieder die Methode ansehen und dort versehen was die Funktion eigentlich wirklich macht. Klarer Fall von nicht lesbar sondern unnötig kompliziert für mich.
lso muss ich mir doch wieder die Methode ansehen und dort versehen was die Funktion eigentlich wirklich macht. Klarer Fall von nicht lesbar sondern unnötig kompliziert für mich.
Schaust Du in die Java-Quellen zu z. B. java.awt.Rectangle, weil Du irgendwo im Code dessen contains()-Methode aufrufst?
Ich verstehe zwar, was Du meinst, aber das ist in meinen Augen zweitrangig. Nicht, weil es keine Rolle spielen würde, sondern weil es eine Frage der Häufigkeit ist. Der Anteil der Fälle, in denen es beim Lesen des Codes darauf ankommt, ob contains() true leifert, wenn der Punkt auf dem Rand liegt, dürfte verschwindend gering sein. Natürlich hängt es davon ab, was der Code macht und das Beispiel ist stark verkürzt. Worauf es mir ankommt: ich möchte auf einen Blick verstehen, was die Methode betreibt. Und hier sehe ich sofort: aha, es wird geprüft, ob der Punkt im Rechteck (wie auch immer) enthalten ist. Dazu muss ich nicht erst vier Bedingungen lesen und verstehen.
Ich stimme @kneitzel vollkommen zu, bis auf:
Das sehe ich etwas anders: ist gibt keine in Zeilen messbare, harte Grenze. Falsch und richtig entscheidet sich an der Lesbarkeit. Und lesbar heißt: ein Blick und ich muss wissen, was das Ding macht.
Und damit gibt es definitiv kein richtig oder falsch. Denn
a) ist es eine extrem individuelle Sache . Was Du lesen kannst, kann ich evtl. nicht lesen und umgekehrt. Bzw. was besser lesbar ist kann sogar eine Frage der Gewohnheit sein. Jemand, der es immer gewohnt war, den Typ mit den den Namen zu packen, der wird ein pszIrgendwas gut lesen können. Du wirst da nur den Kopf schütteln denke ich mal (Zumal man da dann aus dem p ein r machen müsste, weil Pointer in dem Sinne in Java nicht vorkommen sondern Referenzen.) Das zeigt sich dann auch schnell bei Lambda Ausdrücken. Wer das nicht oder nur wenig kann, der wird die nicht lesbar finden. Wer die aber aus dem FF kann, der findet die sehr gut lesbar. Aber wer ist dann die Zielgruppe? Wir verzichten da eher mal um es eben für das ganze Team lesbar zu halten. So kann auch ein Junior Developer ggf. unterstützen. Und uns tut es nicht weh - die alte Schreibweise ist ja nicht ungültig geworden!
b) es kommt auf eine Bewertung an. Das Beispiel mit dem Builder-Aufrufen: Jemand, der alles in wenig Zeilen haben will, wird dies in eine Zeile schreiben wollen. Jemand, der lieber paar Zeilen mehr hat und dafür die Aufrufe schön untereinander, der hat halt andere Prioritäten. Ersterer wird evtl. sagen, dass die IDE das doch einfärbt und dass es so doch gut sichtbar ist oder so ...
c) Es hängt viel an den verwendeten Tools. Beispiel aus b: Angenommen, ich habe eine IDE, die mir so eine lange Codezeile aufdröselt, wenn ich mir der Maus drauf gehe. Dann wäre das evt. ein Grund, alles in eine Zeile zu schreiben - das ist dann halt die Erzeugung eines Objekts. Schön auf einer Zeile. Wenn mich die Details interessieren, dann gehe ich mit der Maus drauf.
Daher durchaus die Aussage: Es gibt kein Richtig oder Falsch. Aber natürlich mit Gesundem Menschenverstand. Das erwähnte komplexe Perl Script auf <= 5 Zeilen wird hoffentlich niemand als lesbar bezeichnen. (Wobei der Typ damals das gut und auch lesbar fand!)
Richtig / Falsch kommt lediglich aus der Erwartungshaltung (Schule/Studium/Arbeitgeber), aber das ändert dennoch nichts an der Tatsache, dass ein Code für mich mit meinen Mitteln und meiner Erfahrung besser oder gleich gut lesbar ist wie ein anderer Code.) Aber klar: Wenn mein Arbeitgeber will, dass so und nicht anders gemacht wird, dann ist das so.
So und nun komme ich daher und weiß nicht ob das contains bedeutet das der Punkt auch auf dem Border liegen darf oder ob er wirklich innerhalb des Rahmens sein muss.... Also muss ich mir doch wieder die Methode ansehen und dort versehen was die Funktion eigentlich wirklich macht. Klarer Fall von nicht lesbar sondern unnötig kompliziert für mich.
Ja, das ist dann die Sache, die mir im .Net Umfeld / Visual Studio so gut gefällt: Da kommt dann die Dokumentation der API zum tragen. Du weißt nicht genau, was das bedeutet? Maus drauf und Dokumentation wird eingeblendet. Und die Library gibt es nicht nur als DLL sondern es kommt noch eine XML mit der Beschreibung mit so dass die IDE das gleich mit anzeigen kann.
==> Tooling entscheidet somit teilweise auch, was man als lesbar empfindet und was nicht.
Sorry, der Opa muss jetzt wieder Anekdoten aus deiner Jugend erzählen ... oder so ähnlich ...
Richtig oder Falsch? Was bedeutet das denn unter dem Strich? Im Rahmen von Software wäre das die Fragestellung: Macht die Software das, was von ihr erwartet wird oder nicht.
Das ist dann ein einfaches ja / nein Kriterium - sozusagen die Abnahme: Alle Anforderungen werden durchgegangen und abgehakt.
Bei Clean Code kann man natürlich klare Regeln aufstellen und dann an Hand dieser Regeln klare Richtig/Falsch Aussagen treffen.
Wenn also jemand eine solche Regel aufstellen kann, dann haben wir tatsächlich auch dieses "Falsch".
Dies setzt aber voraus, dass eine Instanz eben genau diese Regeln aufstellen kann. Eine solche Instanz, die die Regeln global aufstellt, gibt es aber schlicht nicht oder die Regeln sind nicht sehr weitgehend. (Naming Conventions sind z.B. üblich, aber darüber hinaus?)
Das erkennt man ja schon an diesem Thread. Was ist denn nun die Grenze X? 3-4 Zeilen? 7 Zeilen? 10 Zeilen? 20 Zeilen? Oder evtl. doch 30? Oder dann die 200?
Und was zählen wir mit als Codezeile? Und was ist mit Ausnahmen? (Wenn eine Regel sagt, dass etwas falsch ist, dann ist es falsch. Alles andere wäre doch fatal z.B. in einer Prüfungssituation!)
Also selbst wenn 90% der Funktionen <=7 Zeilen haben (Ich würde da 10 Zeilen sagen, aber ich zähle da noch Leerzeilen und so mit und die { kommen im .Net Umfeld in die nächste Zeile ... daher dürfte das 10 Zeilen .Net ungefähr 7 Zeilen Java entsprechen.), dann bedeutet das: jede 10te Funktion liegt drüber!
Aber selbst wenn es 99% und somit 1% wären: Das würde regelmäßig vorkommen! Also kann das keine richtig/falsch Regel darstellen.
Und in der Praxis ist das dann doch auch relevant. Typisches Beispiel sind kurzfristig notwendige Änderungen (Typischerweise bei Bugs):
Hier hat die benötigte Zeit einen sehr hohen Stellenwert. Bei der Analyse kommt heraus, dass irgend etwas sich anders verhält, als gedacht. Da schreibt man dann ggf. erst einmal einen schnellen Workaround um dann die neue Version schnell ins QA geben zu können. Da wird dann nicht angefangen und gesagt: Jetzt müssen wir da alles einmal auf den Kopf stellen, denn mit den neuen Erkenntnissen ist es so und so besser. Zumindest bei uns landet das als ein Backlog-Item im System und wird dann im nächsten Sprint berücksichtigt. Aber eben nicht im Rahmen der Bug-Behebung, so dies da nicht zwingend notwendig ist.
Sprich: Hier kommen dann natürlich betriebliche Belange ins Spiel und Dinge wie Vertragseinhaltung / Gewährleistung sowie Wahrung des Rufes. Und die interessieren einen Manager dann natürlich deutlich mehr als die Anzahl der Zeilen einer Funktion
(Wobei das natürlich ein Punkt des Clean Code ist, der auch in zeitkritischen Situation eingehalten werden kann. Es kostet nun einmal nicht wirklich Zeit, Code aus einer Funktion in eine neue Funktion zu extrahieren.)
Oder habt Ihr da andere Erfahrungen gemacht / eine andere Sichtweise?
Wichtig: Ich will niemanden überzeugen. Das Thema beschäftigt mich halt dann auch etwas und im Augenblick hab ich mal einen kleinen Ruhepunkt hier. Und es beschäftigt mich in so fern, dass ich drüber die Sache nachdenke. Es geht also nicht darum, wie ich euch überzeugen kann, sondern mehr darum, ob meine Überlegungen zutreffen.
Denn jeder der beruflich in dem Bereich tätig ist, wird wissen: Die Gespräche mit anderen sind immer gut. Und es ist wichtig, über sein eigenes Vorgehen nachzudenken und das evtl. auch anzupassen. Kommt in vielen Dingen ja eh ständig vor, da Technology sich ändert.
Oh, ich meinte das etwas anders. Wäre ich Jurist, würde ich es vermutlich etwa so formulieren: entscheidend ist die Frage, ob ein durchschnittlich begabter Entwickler in vertretbarer Zeit die Funktionsweise der Programmfunktion nachvollziehen kann. Es gibt Dinge, wo man allgemein sagen kann: das hat nichts mehr mit Lesbarkeit zu tun. Es gibt nur keine harten Grenzen.
Das Thema beschäftigt mich halt dann auch etwas und im Augenblick hab ich mal einen kleinen Ruhepunkt hier. Und es beschäftigt mich in so fern, dass ich drüber die Sache nachdenke. Es geht also nicht darum, wie ich euch überzeugen kann, sondern mehr darum, ob meine Überlegungen zutreffen.
Wenn mein Code von jedem untalentierten Java programmier Knecht vertanden werden muss, dann kann ich beliebig viel Zeit investieren den Code so lesbar wie möglich zu machen. Das kostet dann aber Zeit und damit Geld.
Nun liegt es an mir (oder meinem Chef/Auftraggeber so ich einen habe) zu entscheiden was für ihn Priorität hat. Schreibe ich den Code so, dass ein talentierter Senior-Software-Developer ihn problemlos versteht, wird die Entwicklung entsprechend schneller und günstiger. Schreibe ich ihn so, dass nur ich ihn verstehe wird es noch günstiger.
Jetzt frag mal als Selbständiger was dein Auftraggerber in 99% der Fälle gerne hätte
Schreibe ich den Code so, dass ein talentierter Senior-Software-Developer ihn problemlos versteht, wird die Entwicklung entsprechend schneller und günstiger.
Muss er nicht. Es kann aber z. B. nicht sein, dass Du als Selbständiger Code ablieferst, den niemand außer Dir versteht. Wenn der Auftrag darin besteht, Code zu liefern, dann muss ich als Auftraggeber nicht explizit darauf hinweisen, dass der Code verständlich sein muss.
Muss er nicht. Es kann aber z. B. nicht sein, dass Du als Selbständiger Code ablieferst, den niemand außer Dir versteht. Wenn der Auftrag darin besteht, Code zu liefern, dann muss ich als Auftraggeber nicht explizit darauf hinweisen, dass der Code verständlich sein muss.
Da haben wir wieder die definitionsfrage. Was ist verständlich? Für wen? Mein Code ist verständlich. Ich habe mal lange Zeit in einer Firma gearbeitet die hatte 5 Programmierer. 2 davon haben genauso gedacht wie ich. Da war es überhaupt kein Problem auch den noch so kryptischten Code untereinander auszutauschen er wurde sofort verstanden. Die anderen beiden haben einfach ganz anders gedacht. Den Code von denen habe ich nie kapiert. Und so ist es doch auch heute noch. Du kannst logisches denken nicht „normieren“. Aber genau das wird hier versucht.
Ich bin mir absolut sicher, dass ich mich sehr schwer tun werde den Code von Mr.Brown zu verstehen, egal wie sauber er programmiert. Weil ich einfach anders „ticke“. Genauso wird er meinen nicht so leicht verstehen weil ich meinen Code, selbst wenn ich ihn zu 100% nach euren Clean Code Regeln schreibe, komplett anders organisieren und konstruieren würde als er es tun würde. Es führt ja auch nicht nur ein Weg zum Ziel. Es gibt immer mehrere. Und der eine ist halt für den einen besser verständlich als der andere.
Das Problem an solchen Prefixen: sie überstehen kein Refactoring. Bei der nächsten Code-Änderung ist aus dem globalen int ein lokaler String geworden, aber der Prefix wurde nicht geändert. Ich hab noch kein Projekt gesehen, in dem sich auf die Prefixe verlassen konnte, das war bisher immer Mehrarbeit.
Ja, das ist dann die Sache, die mir im .Net Umfeld / Visual Studio so gut gefällt: Da kommt dann die Dokumentation der API zum tragen. Du weißt nicht genau, was das bedeutet? Maus drauf und Dokumentation wird eingeblendet. Und die Library gibt es nicht nur als DLL sondern es kommt noch eine XML mit der Beschreibung mit so dass die IDE das gleich mit anzeigen kann.
Ist doch mit Java in den meisten IDEs nicht anders?
Zu jeder Jar mit Code gibt es eine mit Javadoc und meist auch eine mit den Sourcen. Jede vernünftige IDE lädt das und zeigt das auch ohne Probleme an.
Wenn mein Code von jedem untalentierten Java programmier Knecht vertanden werden muss, dann kann ich beliebig viel Zeit investieren den Code so lesbar wie möglich zu machen. Das kostet dann aber Zeit und damit Geld.
Nun liegt es an mir (oder meinem Chef/Auftraggeber so ich einen habe) zu entscheiden was für ihn Priorität hat. Schreibe ich den Code so, dass ein talentierter Senior-Software-Developer ihn problemlos versteht, wird die Entwicklung entsprechend schneller und günstiger. Schreibe ich ihn so, dass nur ich ihn verstehe wird es noch günstiger.
Jetzt frag mal als Selbständiger was dein Auftraggerber in 99% der Fälle gerne hätte
Deine Rechnung geht sowieso nur auf, wenn du davon ausgehst, dass lesbarer Code dich effektiv nur Zeit kostet und keinerlei Vorteil hat. Da würde ich schon den Fehler in deiner Rechnung sehen, vor allem da lesbarer Code selten allein kommt, sondern (meiner Erfahrung nach) meist auch mit mehr und besseren Tests und tendenziell defensiverer Programmierung einher geht.
Aber selbst wenn man davon ausgeht, dass nur von dir lesbarer Code für den gleichen Umfang günstiger ist als einfach lesbarer Code, ist das von den Auftraggeber nur selten klug, dann das billigste zu nehmen. Jeder Code muss irgendwann gewartet und weiterentwickelt werden - und die Folgekosten sind doch deutlich günstiger, je einfacher der Code. Wenn nur du den verstehst, muss uU das ganze Produkt neu entwickelt werden, weil du nicht zur Verfügung steht.
Wenn dem Auftraggeber das Produkt egal ist, wenns einmal programmiert ist, mag das egal sein - nahezu nie ist das aber der Fall.
Aber selbst wenn man davon ausgeht, dass nur von dir lesbarer Code für den gleichen Umfang günstiger ist als einfach lesbarer Code, ist das von den Auftraggeber nur selten klug, dann das billigste zu nehmen. Jeder Code muss irgendwann gewartet und weiterentwickelt werden - und die Folgekosten sind doch deutlich günstiger, je einfacher der Code. Wenn nur du den verstehst, muss uU das ganze Produkt neu entwickelt werden, weil du nicht zur Verfügung steht.
Wenn dem Auftraggeber das Produkt egal ist, wenns einmal programmiert ist, mag das egal sein - nahezu nie ist das aber der Fall.
Welche Software heute hat denn eine Lebenszeit von mehr als 5 Jahren? Das sind doch ganz wenige große CRM Systeme o.ä. Das es da Sinn macht viel Aufwand in die Wartbarkeit zu stecken, will ich hier gar nicht wegreden aber sowas programmieren doch nicht einmal 1 Promille aller Programmierer. In der Regel werden kleine Tools entwickelt die eben nach kurzer Zeit bereits ersetzt werden.
Meine älteste Applikation die noch verwendet wird ist jetzt 7 Jahre alt aber das ist nicht der Standard. Meistens werden nach 2-3 Jahren neue Konzepte und Prozesse im Management entwickelt die dann in neuer Software umgesetzt werden.
Wie viel Mehraufwand ist für dich "viel"? 1%? 5%? 20%? 100%?
Aber wie gesagt: du gehst davon aus, das lesbarer Code für dich nur Zeit kostet und keinen Vorteil hat - und die Annahme ist mMn falsch (ich würd's gern mit Studien untermauern, aber speziell zur "Lesbarkeit" hab ich grad nichts zur Hand, die die ich kenne in Bezug auf Mehraufwand und Qualität beziehen sich eher auf TDD...). Die paar Minuten, die ich jetzt in Refactoring stecke, spar ich morgen Mittag...nächste Woche...nächsten Monat, wenn ich selbst den Code wieder lese. Und nebenbei ist vermutlich noch ein Bg beseitigt worden, der ohne Refactoring nicht aufgefallen wäre.
Und es geht auch keinesfalls nur darum, dass die Anwendung in 2 Jahren noch Wartbar ist, das muss die auch morgen sein. Mit Pech ist die bekommt das Unternehmen morgen ne Anwendung, und übermorgen kann niemand mehr den Bug fixen der beim ersten Produktiveinsatz aufgetreten ist (Stichwort Truck Factor...)
Also woher weisst Du, ob Deine Applikation zu den 1% gehören wird, die länger benutzt wird?
Und selbst wenn es nur 2-3 Jahre sind: Wie willst Du das den warten, wenn Du auf Qualität keinen Wert legst? Es gibt ja doch eine gewisse Gewährleistung. Also an Qualität zu sparen geht schnell nach hinten los.
Und erfahrungsgemäß entstehen durch Sparen an falschen Stellen deutlich höhere Kosten. Und Code, der nicht gewartet werden kann, der ist teuer und nicht akzeptabel.
Welche Software heute hat denn eine Lebenszeit von mehr als 5 Jahren? Das sind doch ganz wenige große CRM Systeme o.ä. Das es da Sinn macht viel Aufwand in die Wartbarkeit zu stecken, will ich hier gar nicht wegreden aber sowas programmieren doch nicht einmal 1 Promille aller Programmierer. In der Regel werden kleine Tools entwickelt die eben nach kurzer Zeit bereits ersetzt werden.
Meine älteste Applikation die noch verwendet wird ist jetzt 7 Jahre alt aber das ist nicht der Standard. Meistens werden nach 2-3 Jahren neue Konzepte und Prozesse im Management entwickelt die dann in neuer Software umgesetzt werden.
Hm, den Trend muss ich irgendwie verschlafen haben. So kurze Nutzungszeiträume kenne ich eigentlich wirklich nur von Tools, die für einmalige Ereignisse, wie etwa Datenmigrationen gebraucht werden. Oder eben gescheiterte Projekte, die ihren Zweck nicht erfüllen. Üblicherweise läuft es in der Wirtschaft ja so, dass man auch einen Nutzen aus seiner Investition ziehen möchte. Von daher sind nach meiner Einschätzung eher 15 oder 20 Jahre normal. Das gilt sowohl für die Nutzungsdauer von Standardsoftware beim Kunden (natürlich in immer neuen Versionen, aber da kann ja trotzdem uralter Code drin stecken), als auch für eigenes inhouse-Gefrickel (dann oft ohne explizite Versionen, sondern in ständigem Wandel am offenen Herzen).
Das habe ich oben schon beantwortet: ein durchschnittlich begabter Entwickler muss in der Lage sein, den Code mit vertretbarem Aufwand nachzuvollziehen.
Den Code von denen habe ich nie kapiert. Und so ist es doch auch heute noch. Du kannst logisches denken nicht „normieren“. Aber genau das wird hier versucht.
Unverständliche Bedienungsanleitungen gelten als Mangel. Da kann sich auch niemand darauf berufen, dass er anders denkt. Natürlich sind hier die angelegten Maßstäbe andere, weil beim Käufer kein Sachverstand vorausgesetzt werden kann.
Stell Dir vor, ich bezahle jemanden einen Haufen Geld dafür, dass er mir Quelltext liefert. Ich bestelle den Quelltext in erster Linie nicht deshalb, um ihn zu kompilieren und das fertige Programm auszuliefern, sondern weil er gepflegt, angepasst, geändert werden soll. Wenn ich davon ausgehen muss, dass der Quelltext von einem durchschnittlichen Entwickler nicht in annehmbarer Zeit verstanden wird, dann nehme ich das Ding nicht ab, weil er mit Mängeln behaftet ist.
Euch ist doch aber aufgefallen, dass sich der TE bis jetzt 0mal gemeldet hat oder?
Wenn man danach googelt wird schnell klar dass: Behaupte etwas falsches im Internet und warte die Reaktionen ab, um an alle richtigen Informationen zu kommen, hier zutreffend ist....
Ok, ich kann mich allerdings auch nicht selber davon lossprechen, weil ich mich ja selber wie wild in diese Diskussion eingemischt habe.
diesen Monolog könntest Du auch mit Dir selber halten - oder ihn auf ein Blatt Papier schreiben und verbrennen - es würde ebensoviel bringen, wie nicht auf die Frage des TE einzugehen oder auf die Frage des TE einzugehen wenngleich er alle Antworten ignoriert also auch nicht stillschweigend zur Kenntnis nimmt.
Umgangssprachlich: Sprechen mit Deinem Toaster hätte denselben Effekt.
Aber verstehe mich nicht falsch, ich respektiere Dein Alter sowie Deine Erfahrungen und freue mich immer wenn jemand nicht borniert ist also andere Ansichten annehmen kann und nicht alles ablehnt.
