Wie lang eine Funktion/Methode?

[MrXeth]

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?

Danke für eure Antworten.

 

[Javinner]

Ich bin 15pkt Info LK`ler

Welchen Geschlechtes du auch sein magst, bitte verständige dich doch klar und deutlich..

wann ihr eine große Funktion / einen Ablauf in mehrer Kleine unterteilt

Immer dann, wenn es nötig ist. Immer dann, wenn eine Methode mehr, als nur eine Aufgabe übernimmt.

 

[temi]

Bei static Funktionen ist es ja klar, dass eigentlich stellvertretend (hardcoded) für die Funktion dort der Quelltext kompiliert wird.

Häh?

 

[Robat]

Welchen Geschlechtes du auch sein magst, bitte verständige dich doch klar und deutlich..

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

 

[Javinner]

Er wollte dir damit mitteilen

Dann wurde ich so eben bedient

 

[Meniskusschaden]

möchte gerne wissen, wann ihr eine große Funktion / einen Ablauf in mehrer Kleine unterteilt.

Immer.

aber ist es nicht klüger mehrere kleine Methoden zu erstellen wie update Queue oder so?

Ja.

Und wie sieht es da mit der Laufzeit aus?

Asymptotisch sollte das keine Rolle spielen und Mikrooptimierungen würde ich erst machen, wenn es sich als notwendig erweist, aber nicht im Vorfeld.

 

[Xyz1]

Ich bin 15pkt Info LK`ler

Ich auch

und möchte gerne wissen, wann ihr eine große Funktion / einen Ablauf in mehrer Kleine unterteilt

Immer.

Bearbeitung: Mist @Meniskusschaden war schneller. ich sollte vielleicht mal nicht crosslesen.

 

[MrXeth]

Häh?

Vergiss es, mein Fehler, hab da was vertauscht.. xD

 

[Xyz1]

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.

 

[thecain]

Wenn man etwas besser kann als der Schnitt dann sollte man das den anderen nicht so um die Ohren hauen.

Ich auch

Der war gut!

 

[mihe7]

Er wollte dir damit mitteilen, dass er in der Oberstufe einen Informatik-Leistungskurs besucht und dort 15 Punkte (Note 1+) hat

Vielleicht wollte er aber auch zeigen, wie wenig Grundwissen man braucht, um 15 Punkte zu bekommen

 

[kneitzel]

Vielleicht wollte er aber auch zeigen, wie wenig Grundwissen man braucht, um 15 Punkte zu bekommen

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.

Ich auch

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

 

[kneitzel]

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

 

[Xyz1]

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

 

[Meniskusschaden]

@kneitzel Das immer bezog sich nicht auf die Größe zu langer Methoden

Mein "immer" aus #6 bezog sich schon darauf.

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.

Die Größe einer solchen Switch-Anweisung wäre aber schon ein Hinweis, über Alternativen nachzudenken.

Und ganz wichtig sind die Namen: Ein Code sollte ohne Kommentare direkt gut lesbar sein!

Ja. Das wäre für mich auch ein ausreichender Grund, einzeilige Funktionen zu schreiben, einfach um der Sache einen Namen geben zu können.

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

 

[mrBrown]

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!"

 

[Xyz1]

Mein "immer" aus #6 bezog sich schon darauf

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.

 

[Thallius]

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

 

[kneitzel]

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

 

[mrBrown]

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