Code-Style: wie verschönert/verbessert ihr die Lesbarkeit großer Dateien?

[ConnorMcLeod]

Zitat:

Zitat von a.def (Beitrag 1356614)

Ich habe nicht selten Prozeduren mit 100 bis 500 Zeilen.
Eine Execute-Prozedur eines Threads hat sogar beinahe 1700 Zeilen und selbst da ist schon verdammt viel in externe Prozeduren ausgelagert.

Solange Du Dich auskennst und im Falle Deines Wegganges niemand extra eingeschult werden muß, ist das total okay.
Ich halte "50 Zeilen" nicht für eine betonierte Regel, sondern eine Richtlinie, die erreichen möchte, alles so kurz/einfach wie möglich zu halten. Wie dieses Ziel erreicht wird, ist wohl eher eine Frage von Gusto/Programmierstil und kann deshalb nicht genau definiert werden. Aber es läßt sich trefflich drüber streiten ;-)

[a.def]

Das mit den 50 Zeilen und dem absoluten Auslagern von Code in Prozeduren hat noch einen ganz anderen negativen Effekt:
man produziert mit Prozedur deutlich mehr Müll als ohne Prozedur.
Denn da wäre der Prozedur-Kopf, begin, end und eventuell noch eine Deklaration im Unit-Kopf.
Sollte man diese Funktion 100x gebrauchen ist das ja OK.
Aber alles unter/bis ~3 Verwendungen + wenige Codezeilen, da benutze ich einfach Copy-Paste.

[EWeiss]

Zitat:

Ich sehe noch nicht, was das mit den Suchpfaden des Compilers zu tun hat.

Weil beim compilieren und debugen der Anwendung inklusive der DLL die pfade der DLL halt unterschiedlich sind.
Du kannst die Suchpfade angeben wie du willst aber letztendlich wird die DLL in unterschiedlichen Ordnern Anwendungs\Pfad abgelegt.

Ich kann das nur lösen indem ich unterschiedliche *.DPR's (Projektdateien) verwende.
Ein einbinden des Suchpfades so das alle Anwendungen auf die Units zugreifen können wird das Problem nicht lösen.
Spätestens beim debuggen scheitert das ganze.

gruss

[Aviator]

Zitat:

Zitat von a.def (Beitrag 1356619)

Aber alles unter/bis ~3 Verwendungen + wenige Codezeilen, da benutze ich einfach Copy-Paste.

Hatte ich früher auch gemacht. Heute lagere ich den Codeteil in eine neue Methode aus, sobald dieser ein zweites Mal benötigt wird. Ansonsten unnötige doppelte Pflege usw.

Bei einem kleinen Quick'n'Dirty Programm oder einem Testprojekt kann man das mal machen. Aber auch da geht das recht schnell. Refactoring --> Methode extrahieren --> Fertsch.

Sofern der Code nicht so vollgemüllt ist das das Refactoring einem den SourceCode total zerschiesst. Ist mir auch schonmal passiert. :evil:

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1356622)

Weil beim compilieren und debugen der Anwendung inklusive der DLL die pfade der DLL halt unterschiedlich sind.
Du kannst die Suchpfade angeben wie du willst aber letztendlich wird die DLL in unterschiedlichen Ordnern Anwendungs\Pfad abgelegt.

Ich kann das nur lösen indem ich unterschiedliche *.DPR's (Projektdateien) verwende.
Ein einbinden des Suchpfades so das alle Anwendungen auf die Units zugreifen können wird das Problem nicht lösen.
Spätestens beim debuggen scheitert das ganze.

Tut mir leid, ich sehe den Zusammenhang immer noch nicht.

Anlass war dieser Satz von bernau:

Zitat:

Da ich aber mehrere Projekte habe, die alle die gleichen Units brauchen (300 Stück), hat es mich immer genervt die Suchpfade in jedem Project anzupassen, wenn mal ein neues Verzeichnis zugefügt wurde.

Mein Hinweis auf das OptionSet stellt lediglich eine Möglichkeit dar, die Suchpfade nur einmal anzupassen anstatt in jedem Projekt.

Was hat das mit DLLs zu tun, die (ob nun aus einem Projekt oder aus mehereren) in verschiedenen Verzeichnisse abgelegt werden? Die DLL wird doch gar nicht im Suchpfad der Units gesucht, sondern allenfalls in der Umgebungsvariable PATH.

[ConnorMcLeod]

Zitat:

Zitat von a.def (Beitrag 1356619)

Aber alles unter/bis ~3 Verwendungen + wenige Codezeilen, da benutze ich einfach Copy-Paste.

Es hat Gründe, warum man es nicht so macht, aber solange Du Dir damit kein Bein stellst - bitte sehr. Wenns dann mal soweit sein wird (und das wird es), kennst Du einen der Gründe aus eigener Erfahrung und ab dann wirst Du anders denken ;-)

[Luckie]

Das Problem bei so einen Copy and waste Vorgehen ist, dass man unter Garantie eine Stelle vergisst, wenn man etwas ändern muss. Und dann geht die Fehlersuche los.

[mm1256]

Yupp. Und darum glaube ich auch, dass die Regel "wenn du einen Code 2x benötigst, dann lagere ihn in eine procedure/function aus" seine Berechtigung hat. Für die Lesbarkeit mag das zwar dann in manchen Fällen etwas schlechter sein, aber für die Wartbarkeit ist es ein Gewinn.

[ConnorMcLeod]

Zitat:

Zitat von mm1256 (Beitrag 1356688)

Yupp. Und darum glaube ich auch, dass die Regel "wenn du einen Code 2x benötigst, dann lagere ihn in eine procedure/function aus" seine Berechtigung hat. Für die Lesbarkeit mag das zwar dann in manchen Fällen etwas schlechter sein, aber für die Wartbarkeit ist es ein Gewinn.

Zustimmung - die Auslagerung ist sinnvoll.
Einspruch - wenn der Funktionsname gut gewählt ist, leidet die Lesbarkeit nicht.

[Sherlock]

Die Lesbarkeit leidet eben nicht darunter, weil man ja den Code durch einen beschreibenden Methodennamen ersetzt. Es geht dann so weit, daß ehemals 500 Zeilen Spaghetti in einer Methode dann zu 30 Zeilen werden, die man bestens lesen und verstehen kann (untendrunter gehts halt wieder ans blutige):

Delphi-Quellcode:

begin
  ErrechneBildGrenzen;
  SetzeMinimalWerte(NeueKoordinaten);
  Muss := VergleicheIstMitSoll(Ist, Soll);
  ZeichneWert(Muss);
{etc...}
end;

Was ist daran auszusetzen? Selbst wenn jeder ersetzte Block nur einmal benutzt wird, so ist die Lesbarkeit für das grobe Überfliegen des Codes und vor allem zum Neueinstieg nicht zu übertreffen.

Edit: What Connor said...

Sherlock