Max Zeilen in einer Procedure

[Edelfix]

Weiß jemand wieviel Zeilen eine Procedure maximal haben darf?

Ich beobachte öfter ein Effekt. Oben in der Leiste wo der Name der Procedure / Funktion angezeigt wird is ab und zu einfach alles leer.

Ich weiß das es eine Maximum Grenze gibt. Wir mussten schon einmal eine Procedure in zwei aufteilen weil der Compiler gestreikt hatte. Es ist leider zu lange her. Es ist ein sehr altes Projekt und wir haben mit viel Spagetti Quelltext zu tun.

[Neutral General]

Die maximale Länge einer Procedure ist weit unter der des Compilers :P

[Uwe Raabe]

Zitat:

Zitat von Edelfix (Beitrag 1495917)

Weiß jemand wieviel Zeilen eine Procedure maximal haben darf?

Faustregel: Nicht mehr als auf dem Bildschirm ohne zu scrollen angezeigt werden können. Mehr ist schlecht für die Lesbarkeit.

Den Compiler würde ich dazu gar nicht erst befragen. Der ist da ziemlich schmerzbefreit und definitiv nicht kompetent genug für eine Antwort darauf.

[Sinspin]

Zitat:

Zitat von Uwe Raabe (Beitrag 1495922)

Faustregel: Nicht mehr als auf dem Bildschirm ohne zu scrollen angezeigt werden können. Mehr ist schlecht für die Lesbarkeit.

Also brauche ich nur einen großen Monitor. Oder die Schrift schön klein machen.

Ich finde es wichtiger den Quelltext ordentlich zu dokumentieren und Bezeichnern verständliche Namen zu geben.
Natürlich sollte man immer nachdenken was logische Blöcke sind die man zusammenfassen kann. Aber manchmal wird es halt ein bisschen mehr.

[Delphi-Laie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1495922)

Zitat:

Zitat von Edelfix (Beitrag 1495917)

Weiß jemand wieviel Zeilen eine Procedure maximal haben darf?

Faustregel: Nicht mehr als auf dem Bildschirm ohne zu scrollen angezeigt werden können. Mehr ist schlecht für die Lesbarkeit.

Den Compiler würde ich dazu gar nicht erst befragen. Der ist da ziemlich schmerzbefreit und definitiv nicht kompetent genug für eine Antwort darauf.

Ist das jetzt ein Scherz, Ironie?

Wer, wenn nicht der Compiler, ist der kompetente Auskunftsschalter, jedenfalls dann, wenn ein evtl. vorhandenes Limit überschritten wurde?!

Ich kann mich noch an Zeiten erinnern - entweder war es das originale Pascal oder eines der frühen Turbo-Pascals mit der damals revolutionären IDE, das tatsächlich noch die Compiler-Fehlermeldung "source code too large or too complex" (oder so ähnlich) hatte. Ich sah sie später nie wieder.

Auch beim Turbo-Pascal 6.0 kann ich mich an eine Restriktion erinnern: Dem war eines meiner Programme zu groß, aus heutiger Sicht eher bescheiden. Also lagerte ich den Ein- und auch den Ausgabeteil jeweils in eine eigene Prozedur aus, die ich jeweils, also an passender Stelle, nur einmal aufrief. Das Programm wurde dadurch nur (minimal) komplexer und der Quellcode nur unnötig etwas größer. Was der Compiler davon hatte, erschloß sich mir nie.

So gesehen, ist die Frage von Edelfix vielleicht doch durchaus berechtigt.

[sakura]

Zitat:

Zitat von Delphi-Laie (Beitrag 1495941)

Ist das jetzt ein Scherz, Ironie?

Nein, das ist sauberes entwickeln. Eine "Monitorlänge" ist einfach ein Richtwert. Keiner reißt einem den Kopf ab, wenn es mal zwei oder gar drei sein, aber die Übersichtlichkeit ist eine wichtige Richtlinie.

Aus Sicht des Compilers gibt es keine feste Grenze, das hängt eher vom verfügbaren Speicher ab (der Compiler kann bis zu 2GB nutzen für alles zusammen).

...:cat:...

[Delbor]

Hi zusammen

Zitat:

Zitat von Sinspin (Beitrag 1495937)

Zitat:

Zitat von Uwe Raabe (Beitrag 1495922)

Faustregel: Nicht mehr als auf dem Bildschirm ohne zu scrollen angezeigt werden können. Mehr ist schlecht für die Lesbarkeit.

Also brauche ich nur einen großen Monitor. Oder die Schrift schön klein machen.

Ich finde es wichtiger den Quelltext ordentlich zu dokumentieren und Bezeichnern verständliche Namen zu geben.
Natürlich sollte man immer nachdenken was logische Blöcke sind die man zusammenfassen kann. Aber manchmal wird es halt ein bisschen mehr.

Ein grosser Monitor ist nicht zuverachten, bzw. sehr hilfreich. Hingegen solllte die Schriftgrösse so eingestellt werden, dass die Lesbarkeit nicht darunter leidet.

Beim entwerfen einer Prozedur entstehen bei mir öfters wahre Monster, so dass der Monitor gerne noch 2 bis 3x höher sein dürfte. Diese Gewaltsdinger teile ich im Anschluss an die Entwurfsphase in mehrere kleinere Prozeduren auf. Das hat den Vorteil, dass ich die entstandenen Prozeduren mit einem Blick überschauen, aber auch aus andern Programmteilen heraus aufrufen kann.

Ab etwa sechs bis acht Zeilen sollte man sich über eine Aufteilung Gedanken machen.

Gruss
Delbor

[himitsu]

Ach darum nimmt man einen SAMSUNG C49G94TSSR 49 Zoll WQHD hochkannt, mit Small Font 4 im Codeeditor?


Quelle: https://twitter.com/toms_rocket/stat...94636582817793


Ich hab wegen Ausfall eines Monitors grad sowas, was bei uns frei rumstand, bloß nicht curved, und das macht mich schon bissl wuschig ... aber im Hochformat wäre gerade eh schöner.
Bei 1200er Höhe passt so auch gleich mehr drauf.

[MyRealName]

Ich habe einen dieser 49", macht sich echt gut mit 1440p. Aber normale Schriftgröße in Delphi. Ist halt wir 2x 2k Monitore mit 27", nur ohne störenden Mittelstreifen :-D
Ich tendiere auch zu Prozedurlängen von max. 1 Bildschirm.

[Delbor]

Hi zusammen

Zitat:

Zitat von himitsu (Beitrag 1495961)

Ach darum nimmt man einen SAMSUNG C49G94TSSR 49 Zoll WQHD hochkannt, mit Small Font 4 im Codeeditor?

Grins

Gruss
Delbor

[Delphi-Laie]

Dieses Thema hat vermutlich das Potential für einen ideologischen Grabenkrieg.

Folgt man diesem Dogma "Prozedur (oder eben Funktion) nicht größer als Bildschirm", muß man das Programm ggf. unnötig ziseliert "zerhacken". Das bläht wahrscheinlich nicht nur das Compilat unnötig auf. Es erscheinen unnötig viele Unterprogramme im Code-Explorer. Und spätestens dann bekommt die behauptete "größere Übersichtlichkeit" ggf. ihre ersten Risse.

Außerdem bekommt man bei einem "kompakten" Quellcode durchaus wesentlich mehr Code auf den Bildschirm, insofern ist das wirklich nur eine Faustregel. Inwieweit das dann übersichtlicher ist, ist sicher auch eine Geschmacksfrage (ich mag solchen Quellcode).

[Sherlock]

Grundsätzlich kann man alle Deine Behauptungen mit einem "stimmt so nicht" kontern, @Delphi-Laie. Und zwar genau dann, wenn es um mehr als ein Projekt, mehr als einen Entwickler und mehr als ein Jahr Entwicklungszeit geht.

Übersichtlichkeit ist in den genannten Fällen Trumpf. Und Übersicht bekommt man in erster Linie durch kurze Codeblöcke.

Sherlock

[Edelfix]

Ich meine Proceduren von über 5000 Zeilen. Ich meine das wir eine aufteilen mussten bei etwa 5000. Wir haben mehrere Proceduren von 2000 Zeilen.

Das Projekt gibt es sein etwa 1990.

Wenn es einen Wert gäbe nach dem man gehen könnte dann währe das ein Argument um meine Kollegen davon zu überzeugen die Proceduren zu kürzen. Aber es funktioniert ja...

[himitsu]

Du kannst ja mal ins Projekt-Menü schauen und dir die Metriken und Audits generieren lassen. (keine Angst, falls es mal "kurz" bissl hängt / ewig dauert)

[Uwe Raabe]

Bei automatisch aus IBM RPG II Programmen generierten Units haben wir Methoden im Bereich von 15.000 bis 30.000 Zeilen (eventuell auch noch mehr). Die sind zwar im Delphi IDE-Editor etwas zäh, aber der Compiler hat sich bisher noch nicht beschwert.

[freejay]

Wow! Kein einziger hat auf die Frage des Threaderstellers geantwortet sondern alle haben nur Klugscheißereien über "wie lang sollte eine Prozedur maximal sein" von sich gegeben.

Da war ich in diesem Forum eigentlich besseres gewohnt.

Ich weiß leider nicht, wie lang eine Prozedur maximal sein darf.

[himitsu]

sein darf sie laaaaaaang (bis der Compiler abraucht, also bestimmt locker millionen Zeilen),
aber sein sollte sie es nicht. :roll:

[Uwe Raabe]

Zitat:

Zitat von freejay (Beitrag 1496069)

Wow! Kein einziger hat auf die Frage des Threaderstellers geantwortet

Nun ja, die eigentliche Frage

Zitat:

Zitat von Edelfix (Beitrag 1495917)

Weiß jemand wieviel Zeilen eine Procedure maximal haben darf?

kann streng genommen nur mit Ja oder gar nicht beantwortet werden. Es hat sich offenbar nur niemand zu dieser Antwort bewogen gefühlt, wenn es denn überhaupt jemanden solches gibt. Vielleicht, weil die Antwort dem Fragesteller kaum etwas bringen würde, weil er das was er fragte eigentlich gar nicht wirklich wissen wollte.

Davon abgesehen empfinde ich die sogenannten Klugscheißereien als deutlich brauchbarere Antworten als ein simples "weiß ich nicht" von Hunderten von Forenmitgliedern und diesem Forum durchaus würdig.

Zumal es ja verschiedene Instanzen gibt, die ein solches Limit vorgeben können. Neben (eventuell) dem Compiler kann es auch der Castalia Parser sein, der für die angesprochenen Anzeigen in der Leiste zuständig ist, oder der Editor Parser oder Code Insight oder sogar die RAM-Ausstattung des Rechners, um nur ein paar zu nennen. Die wichtigere Instanz ist aber der Coding Style Guide des Unternehmens, des Chief Developers oder des individuellen Entwicklers, der in der Regel deutlich restriktiver ist und ganz andere Ziele verfolgt (zum Beispiel die Übersichtlichkeit). Alles sind plausible Antworten auf die Frage "Wie viele Zeilen darf eine Procedure haben?". Am Ende wird man sich auf die kleinste Zahl in den Antworten einlassen müssen. Das jetzt als Klugscheißerei abzutun finde ich ehrlich gesagt etwas befremdlich.

[Chemiker]

Hallo,

auf meinen PC habe ich eine Procedure mit 50400 Zeile grade getestet wird ohne Probleme unter Delphi 11 ausgeführt. Trotzdem würde ich nur Proceduren/Functionen mit 50 - 100 Zeilen anstreben, um die Übersicht nicht zu verlieren.

Bis bald Chemiker

[himitsu]

Du kannst ja auch mit $REGION die Funktion noch etwas unterteilen.

Hatte ich bei einigen Funktionen mal gemacht, wo aktuell noch keine größeren Umbauarbeiten geplant waren.

[sakura]

Zitat:

Zitat von freejay (Beitrag 1496069)

Wow! Kein einziger hat auf die Frage des Threaderstellers geantwortet sondern alle haben nur Klugscheißereie

Wow, Du hast eindeutig nicht alles gelesen ;-)

Zitat:

Aus Sicht des Compilers gibt es keine feste Grenze, das hängt eher vom verfügbaren Speicher ab (der Compiler kann bis zu 2GB nutzen für alles zusammen).

...:cat:...

[Jasocul]

Solange die Prozedur/Funktion/Methode trivial ist, ist die Anzahl der Zeilen relativ uninteressant. Ich habe auch welche, die mal 200-300 Zeilen haben. Meistens sind das Initialisierungen, einlesen von Einstellungen und geringfügige Aufbereitung (z.B. Backslash am Ende von Pfadangaben sicherstellen). Meistens unterteile ich durch Leerzeilen und Kommentare noch einzelne Blöcke (Regions wären auch denkbar, wie Himitsu schon schrieb). Natürlich könnte man diese Blöcke in weitere Prozeduren auslagern, aber es erhöht die Lesbarkeit nicht wirklich und man muss bei der Fehlersuche auch noch durch die Prozeduren springen.
Würde ich die Leerzeilen, Kommentare und nicht notwendiges "begin...end" weglassen, könnte ich wahrscheinlich noch 10-20% sparen. Das wurden den Source aber weniger lesbar machen.

Meine übliche Vorgehensweise:
Wenn eine unfamgreiche Prozedur fertig ist, sehe ich mir die nochmal an und überlege, ob ich die in einem Jahr noch ohne Probleme sofort durchschaue. Ist das nicht der Fall, gibt es ein Refactoring. Kommt aber selten vor, da ich in der Regel sofort merke, wenn etwas komplizierter wird und ausgelagert werden muss. Das passiert zum Beispiel, wenn ich für mich selbst Kommentare in den Source schreiben muss, damit ich weiß, was da gemacht wird. Das ist auch relativ unbahängig von der Anzahl der Zeilen.

Aber mal so nebenbei: Es gibt wirklich schlimmeres alles lange Prozeduren. Ich muss immer wieder alte Sourcen von einem Vorgänger bearbeiten. Lange Prozeduren mit globalen, nicht sprechenden Variablen, with-Elementen und ohne Kommentare (Kommentare gibt es nur am Anfang der Prozedur, damit man weiß, dass z.B. die Prozedur "Initalisierung" die Variablen initialisiert). Wenn dort Fehler drin sind oder Anpassung erforderlich werden, kann ich erstmal 1-2 Tage opfern, um die Sourcen überhaupt zu verstehen. Dass der die Form-Variablen in der Klasse verwendet, hat ist dann auch immer wieder spannend. Und wozu soll man Fehlerbehandlung machen oder try...except/finally verwenden. Das wird völlig überbewertet.
Sorry, musste ich gerade mal loswerden :kotz:

[Edelfix]

Ich bedanke mich für ALLE Beiträge.

Mich hatte hauptsächlich der technische Part interessiert. Ob der Compiler ab einer gewissen Größe überfordert ist. Und diese Frage wurde beantwortet.
Aber auch andere Beiträge fand ich interessant.

[himitsu]

Zitat:

Aus Sicht des Compilers gibt es keine feste Grenze, das hängt eher vom verfügbaren Speicher ab (der Compiler kann bis zu 2GB nutzen für alles zusammen).

Drumm schafft die Commandozeile (DCC32) auch wesentlich mehr, als der Inline-Compiler, weil der sich ja den RAM mit der IDE teilt.

Aber im Zusammenhang mit LSP trennt sich das wohl auch immer mehr auf.