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

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