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

[a.def]

Aktuell bearbeite ich alten Quellcode und hübsche ihn mit Kommentaren und weiteren Dingen auf.

So habe ich mir z.B. angewöhnt große zusammenhängende Code-Passagen folgendermaßen zu markieren und sichtbar vom Rest zu trennen

Delphi-Quellcode:

// Code description ...
// ==============================================================================================================================================
ganz viel code!
// ==============================================================================================================================================

Macht ihr auch soetwas oder eher gar nicht?

Mir hilft Cnpack dabei sehr. Eine Tastenkombination und schon habe ich meinen Block im Editor.

[himitsu]

Delphi-Quellcode:

{$REGION 'Code description'}
ganz viel code!
{$ENDREGION}

:roll:


Und dann könnte man es eventuell mit etwas Refactoring versuchen.

[Luckie]

Mit Kommentaren aufhübschen? Ein Widerspruch in sich. :?

[brechi]

Bei mir gibt es keine großen Dateien. Ganz einfach :)

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1356531)

Und dann könnte man es eventuell mit etwas Refactoring versuchen.

Also praktisch: Aus den zusammenhängenden Code-Blöcken kann eine Funktion (oder ein Objekt) werden. Mit etwas Glück kannst du dir dann ein paar Kommentare sparen, weil du den Funktionen sinnvolle Namen geben kannst.

Zitat:

Zitat von Luckie (Beitrag 1356532)

Mit Kommentaren aufhübschen? Ein Widerspruch in sich. :?

Ich weiß nicht, wenn man sich in Legacy-Code einarbeitet, dann sind ein paar Kommentare/Notizen als erster Schritt sicher nicht die schlimmste Idee.

[Luckie]

Ja. Aber sie sollten nach der Überarbeitung wieder verschwunden sein.

[Sherlock]

Ich bleibe dabei: Kommentare sind nicht überflüssig, und machen auch nichts kaputt. Ich habe letzte Woche vor einem Codestück gesessen, und dachte mir "Was hat dieser Drecksack sich dabei gedacht?" Dazu muss ich folgendes noch erklären:
1. Der Code war zwei Monate alt
2. Der Drecksack bin ich :twisted:

Die entsprechende Stelle war ein äußerst eleganter Zweizeiler, nur leider mußte ich eine gute Viertelstunde darüber grübeln, was ich mir dabei gedacht habe. Was es machen sollte war klar, nur verstand ich nicht mehr wie, und wie ist manchmal schon wichtig... Ein paar erhellende Worte darüber oder daneben hätten mein Zeitkonto etwas schonen können, jetzt haben die grauen Herren sich wieder eine Zigarre auf meine Kosten rollen können ;)

Aber zum Thema: Pro Klasse bzw. Klassenbaum eine Unit, und pro Methode nicht mehr als 50 Zeilen, dann wirds schön übersichtlich.

Sherlock

[Der schöne Günther]

Zitat:

Zitat von Sherlock (Beitrag 1356538)

Pro Klasse bzw. Klassenbaum eine Unit, und pro Methode nicht mehr als 50 Zeilen, dann wirds schön übersichtlich.

Zitat:

Zitat von brechi (Beitrag 1356533)

Bei mir gibt es keine großen Dateien. Ganz einfach :)

So einfach ist das? Ja. 8-)

[EWeiss]

Zitat:

nur verstand ich nicht mehr wie, und wie ist manchmal schon wichtig...

Sehe ich genauso.

Mit unter schreibt man code den man nach Jahren portieren oder nochmal überarbeiten will da man sein wissen verbessert hat.
Da ist es schon hilfreich wenn man vorher ein Kommentar (Sinnvollen) hinterlassen hat.
So was wie "Start der Anwendung" in FormCreate zählt natürlich nicht dazu.

Zitat:

Pro Klasse bzw. Klassenbaum eine Unit, und pro Methode nicht mehr als 50 Zeilen, dann wirds schön übersichtlich.

Dito :thumb:

gruss

[a.def]

Zitat:

Pro Klasse bzw. Klassenbaum eine Unit, und pro Methode nicht mehr als 50 Zeilen, dann wirds schön übersichtlich.

Ich habe irgendwann angefangen thematisch alle meine Prozeduren und Funktionen und eigene Dateien auszulagern.
Ich habe zwar noch immer relativ große Dateien aber wenn man eine eigene Sortierung der Dateien in der Projektverwaltung hätte, würde ich ich viel mehr und viel kleinere Dateien haben.

[Daniel]

Zitat:

Zitat von Sherlock (Beitrag 1356538)

[...]und pro Methode nicht mehr als 50 Zeilen, dann wirds schön übersichtlich.

... wenn da nur nicht diese furchtbare Lücke zwischen Theorie und Praxis wäre. ;-)

[Sherlock]

Zitat:

Zitat von Daniel (Beitrag 1356550)

Zitat:

Zitat von Sherlock (Beitrag 1356538)

[...]und pro Methode nicht mehr als 50 Zeilen, dann wirds schön übersichtlich.

... wenn da nur nicht diese furchtbare Lücke zwischen Theorie und Praxis wäre. ;-)

:-D

Wem sagst Du das?

Sherlock

[EWeiss]

Zitat:

wenn da nur nicht diese furchtbare Lücke zwischen Theorie und Praxis wäre.

Die Praxis ist die das bsp. früher unter VB6 ein Limit pro Datei 64K galt.
Was natürlich auf den heutigen stand nicht mehr kontrolliert wird von keinem mir bekannten Compiler.

gruss

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1356549)

wenn man eine eigene Sortierung der Dateien in der Projektverwaltung hätte

Ich gruppiere meine Dateien im Projekt in Unterverzeichnissen. Damit lässt sich schon so Einiges erreichen.

[ConnorMcLeod]

Wenn man das selbst in der Hand hat, dann ist ja alles kein Problem...
Für Interfaces, Klassen, Konstanten, Resourcestrings, Hilfsfunktionen jeweils eigene Units.
Die Units mglw in Unterverzeichnissen strukturiert speichern.
Funktionen möglichst klein halten, ca. 15-50 Zeilen.
Funktionsköpfe und Klassendefinitionen gut beschreiben.

so weit so gut.

Die unlesbaren kilometerlangen Spaghetticodes erbt man ja meistens von Leuten, die nicht mehr greifbar sind und da sitzt das Problem, dem ich so begegne:

Nach dem ersten Sichten, wie alles zusammenhängt, kommt bei mir erstmal ein Codeformatter dran.
zB "JEDI Code Formatter", mein derzeitiger Favorit.

Danach werden alle Funktionen und Klassen möglichst ausgelagert in eigene Dateien, siehe oben. Die Dateien bekommen selbsterklärende Namen.
Im Zuge dessen werden mittels Refactoring Variablen sprechender benamst, Konstante mit selbsterklärende Namen eingeführt und auch Kommentare ergänzt, aber nicht massiv. Der Sinn sollte sich möglichst durch den Code erschliessen. Meine wirksamste "Waffe" sind Funktionsköpfe, in denen beschrieben wird, was die Funktion macht:

Delphi-Quellcode:

{-----------------------------------------------------------------------------
  Procedure: ColorPercentLighter
  Purpose:   Produce a brighter color value
  Author:    Connor McLeod
  Date:      19.Dez.2016
  Arguments: AColor: start with this colour and make it brighter
             APercent: resulting colour will be APercent brighter than AColor
  Result:    TColor
  Example:   MyControl.Font.Color := ColorPercentLighter(clYellow, 7);
  History:
  Remarks:
  Todo:
-----------------------------------------------------------------------------}

[bernau]

Zitat:

Zitat von Uwe Raabe (Beitrag 1356559)

Zitat:

Zitat von a.def (Beitrag 1356549)

wenn man eine eigene Sortierung der Dateien in der Projektverwaltung hätte

Ich gruppiere meine Dateien im Projekt in Unterverzeichnissen. Damit lässt sich schon so Einiges erreichen.

Habe ich früher auch gemacht. 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.

Mittlerweile versuche ich alles in einem Verzeichnis zu halten und verwende immer mehr Namespaces, welche mir die gleiche logische Funktionalität bieten wie Verzeichnisse.

[ConnorMcLeod]

Das klingt ganz nach einer globalen Lib, die in ein eigenes, übergeordnetes Verzeichnis kommt ;-)

[Der schöne Günther]

Bzw. eigenes Repo.

[a.def]

Zitat:

Zitat von bernau (Beitrag 1356567)

Habe ich früher auch gemacht. Da ich aber mehrere Projekte habe, die alle die gleichen Units brauchen (300 Stück)

Bin ich froh, dass ich meine Dateien, welche ich in mehreren Projekten brauche, an einer Hand abzählen kann.

[Uwe Raabe]

Zitat:

Zitat von bernau (Beitrag 1356567)

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.

Units, die direkt dem Projekt hinzugefügt werden (un um die geht es hier gerade), benötigen keinen entsprechenden Eintrag im Suchpfad.

Übrigens könnte man das auch mit einem verlinkten OptionSet vereinfachen.

[mm1256]

Zitat:

Zitat von Uwe Raabe

direkt dem Projekt hinzugefügt werden (un um die geht es hier gerade), benötigen keinen entsprechenden Eintrag im Suchpfad.

Na ja, 300 Units in der Uses-Section in der .dpr sind auch nicht gerade der Hit. Das Problem umgehe ich manchmal auch über einen Suchpfad-Eintrag.

Zitat:

Zitat von Uwe Raabe

Übrigens könnte man das auch mit einem verlinkten OptionSet vereinfachen.

Darf ich mal nachfragen, was weinst du mit bzw. was ist ein verlinktes OptionSet?

[Luckie]

Zitat:

Zitat von Sherlock (Beitrag 1356538)

Ich bleibe dabei: Kommentare sind nicht überflüssig, und machen auch nichts kaputt. Ich habe letzte Woche vor einem Codestück gesessen, und dachte mir "Was hat dieser Drecksack sich dabei gedacht?" Dazu muss ich folgendes noch erklären:
1. Der Code war zwei Monate alt
2. Der Drecksack bin ich :twisted:

Das ist etwas anderes.

[ConnorMcLeod]

Nö. Ist doch egal, wer der Drecksack war. Wenn ein tieferes Verständnis nötig ist, kann das ruhig in einem Kommentar erklärt werden.

[Uwe Raabe]

Zitat:

Zitat von mm1256 (Beitrag 1356581)

Na ja, 300 Units in der Uses-Section in der .dpr sind auch nicht gerade der Hit. Das Problem umgehe ich manchmal auch über einen Suchpfad-Eintrag.

Der Aufhänger war die Sortierung der Units im Projekt-Manager. Units, die nicht direkt im Projekt eingebunden sind, tauchen dort gar nicht auf. Deswegen zählen deine 300 Units hier nicht.

Zitat:

Zitat von mm1256 (Beitrag 1356581)

Darf ich mal nachfragen, was weinst du mit bzw. was ist ein verlinktes OptionSet?

Auf Deutsch: Optionsgruppe

• im Projektmanager Rechtsklick auf Build-Konfigurationen
• Neue Optionsgruppe...
• Pfad auswählen und Dateinamen vergeben
• wenn nötig: Zweig aufklappen
• Rechtsklick auf neues Optset
• Bearbeiten
• Suchpfad eintragen und OK klicken
• OptSet per Drag and Drop in die Build-Konfigurationen der anderen Projekte kopieren

Wenn du jetzt Änderungen in dem OptSet machst, wirken die sich auf alle Projekte aus, in denen das verwendet wird.

[mm1256]

Zitat:

Zitat von Uwe Raabe (Beitrag 1356596)

Wenn du jetzt Änderungen in dem OptSet machst, wirken die sich auf alle Projekte aus, in denen das verwendet wird.

Vielen Dank Uwe für die Mühe! Das kannte/wusste ich noch gar nicht. Ein schöner Tag, wieder was gelernt. Werde es heute Abend mal ausprobieren an einem Testprojekt.

[p80286]

Zitat:

Zitat von Luckie (Beitrag 1356587)

Zitat:

Zitat von Sherlock (Beitrag 1356538)

Ich bleibe dabei: Kommentare sind nicht überflüssig, und machen auch nichts kaputt. Ich habe letzte Woche vor einem Codestück gesessen, und dachte mir "Was hat dieser Drecksack sich dabei gedacht?" Dazu muss ich folgendes noch erklären:
1. Der Code war zwei Monate alt
2. Der Drecksack bin ich :twisted:

Das ist etwas anderes.

Nää, Wenn die Drecksäcke älter werden, und öfters auf anderen Hochzeiten tanzen, dann zeigt sich in solchen Situationen, das die eine oder andere Benennung nur in einem bestimmten Kontext verständlich ist. Allerdings ist es immer ein Erfolgserlebnis erneut heraus zu bekommen wofür der Code in dieser form gedacht war.

Übrigens halte ich

Delphi-Quellcode:

{-------- ab hier gehts los -------}

für einen recht sinnvollen Kommentar, wenn z.B. vorher Dutzende von Zeilen mit z.B. Initialisierung und Verifizierung von Werten stehen.

Gruß
K-H

[EWeiss]

Zitat:

Wenn du jetzt Änderungen in dem OptSet machst, wirken die sich auf alle Projekte aus, in denen das verwendet wird.

Das Problem ist nur bei DLL's und anhängige Pfade.

Habe ich zwei Anwendungen welche die gleiche DLL verwenden..
Die erste Anwendung x legt die DLL beim kompilieren in den Pfad x/bin ab die zweite in y/build
Was dann?

gruss

[Delphi-Laie]

Zitat:

Zitat von Sherlock (Beitrag 1356538)

[..]pro Methode nicht mehr als 50 Zeilen, dann wirds schön übersichtlich.

Ist für mich kein Dogma, zumal diese 50 Zeilen mit größter Wahrscheinlichkeit ein willkürlicher Wert sind.

Je weniger Codezeilen man pro Methode schreibt, desto mehr Funktionalität muß man auslagern, was weitere Unterprogramme bedeutet. Die eine - lokale - Übersichtlichkeit wird mit Verschlechterung der anderen - globalen - Übersichtlichkeit erkauft, m.E. zu teuer.

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1356609)

Das Problem ist nur bei DLL's und anhängige Pfade.

Habe ich zwei Anwendungen welche die gleiche DLL verwenden..
Die erste Anwendung x legt die DLL beim kompilieren in den Pfad x/bin ab die zweite in y/build
Was dann?

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

[a.def]

Zitat:

Zitat von Delphi-Laie (Beitrag 1356610)

Je weniger Codezeilen man pro Methode schreibt, desto mehr Funktionalität muß man auslagern, was weitere Unterprogramme bedeutet.

Sehe ich auch so.
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.

[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