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

[Delphi-Laie]

Zitat von Sherlock:

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

[sakura]

Zitat von BUG:

Zitat von Luckie:

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.

Wenn Luckies Aussage als "Blanket Statement" gemeint ist, dann:

Sollte es sich aber auf solche Dinge beziehen, dann:

Delphi-Quellcode:

// ==============================================================================================================================================
ganz viel code!
// ==============================================================================================================================================

Yes:

Solche "Formatierungslinien" und Ähnliches sind für mich ein Graus, dann doch lieber Tools wie GExperts nutzen, die im Code-Editor die Abschnitte optisch hervorheben.

Aber Quellcode komplett ohne jegliche Kommentare ist aus meiner Sicht ein generelles No-Go, egal wie klein die Unit ist.

......

[Stevie]

Zitat von sakura:

Quellcode komplett ohne jegliche Kommentare ist aus meiner Sicht ein generelles No-Go, egal wie klein die Unit ist.

Und was genau soll man bei selbsterklärendem Code kommentieren?

Siehe auch: https://blog.codinghorror.com/coding-without-comments/

[sakura]

Zitat von Stevie:

Und was genau soll man bei selbsterklärendem Code kommentieren?

Meiner Erfahrung nach gibt es den nicht
Aus der genannten Seite:

Zitat:

Perhaps that's the dirty little secret of code comments: to write good comments you have to be a good writer.

Was meine ich mit "gibt es nicht" - je nach Level der anderen mitarbeitenden (zukünftigen) Entwickler - sowohl generell, als auch Sprach- bzw. Projekt-spezifisch, gibt es in komplexen Systemen nichts, wo nicht ein wenig Dokumentation angebracht ist. Sei es eine Beschreibung des Typen, der Methodenparameter, auftretender Exceptions, oder - innerhalb der Methode - die Logik. Letzteres ist das, was oft am wenigsten nötig ist, aber Schnittstellen und Methoden sollten meiner Erfahrung nach immer eine Beschreibung mit sich bringen.

......

[Stevie]

Zitat von sakura:

Was meine ich mit "gibt es nicht" - je nach Level der anderen mitarbeitenden (zukünftigen) Entwickler - sowohl generell, als auch Sprach- bzw. Projekt-spezifisch, gibt es in komplexen Systemen nichts, wo nicht ein wenig Dokumentation angebracht ist.

Solche Dokumentation zum "Großen Ganzen" findet sich aber eher nicht innerhalb einer bestimmten Sourcecode Datei.

Zitat von sakura:

Sei es eine Beschreibung des Typen, der Methodenparameter, auftretender Exceptions, oder - innerhalb der Methode - die Logik. Letzteres ist das, was oft am wenigsten nötig ist, aber Schnittstellen und Methoden sollten meiner Erfahrung nach immer eine Beschreibung mit sich bringen.

Kann man sich das meiste von sparen, indem man die Dinge entsprechend benennt - siehe Beispiel von Jeff im Artikel.
Es reicht allerdings nicht nur eine gute Benamung sondern auch das Einhalten, bestimmter Prinzipien, z.B. des Single Level of Abstraction - womit man aus dokumentier/kommentierwürdigen if/while/for- Code Klumpen einfach verständliche und selbsterklärende Subroutinen formen kann.

Übrigens habe ich nicht gesagt, dass man nix dokumentieren/kommentieren sollte, sondern, dass ich deiner Aussage, dass jeglicher Code, sei er noch so kurz, Kommentare aufweisen muss, nicht zustimme - bzw nachfragte, um welche Kommentare es sich dort denn handeln solle. Dass du nun Beispiele nennst, wo Dokumentation und Kommentare notwendig sind, beantwortet diese Frage nicht.

[himitsu]

Zitat von Stevie:

Übrigens habe ich nicht gesagt, dass man nix dokumentieren/kommentieren sollte, sondern, dass ich deiner Aussage, dass jeglicher Code, sei er noch so kurz, Kommentare aufweisen muss, nicht zustimme - bzw nachfragte, um welche Kommentare es sich dort denn handeln solle. Dass du nun Beispiele nennst, wo Dokumentation und Kommentare notwendig sind, beantwortet diese Frage nicht.

Delphi-Quellcode:

///   <summary>
///     Das ist die Funktion Sum aus der Datei Unit1.
///   </summary>
function Sum(A, B: Integer): Integer;
var
  Temp: Integer;  // eine lokale Variable und wehe jemand meckert, aber ich hatte sonst nichts zum Kommentieren
begin
  Temp := A + B;  // beide Zahlen addieren
  Result := Temp;  // weist das Ergebnis zu
end;

[p80286]

Zitat von Stevie:

Übrigens habe ich nicht gesagt, dass man nix dokumentieren/kommentieren sollte, sondern, dass ich deiner Aussage, dass jeglicher Code, sei er noch so kurz, Kommentare aufweisen muss, nicht zustimme - bzw nachfragte, um welche Kommentare es sich dort denn handeln solle. Dass du nun Beispiele nennst, wo Dokumentation und Kommentare notwendig sind, beantwortet diese Frage nicht.

Ein Kommentar ist überall da notwendig, wo der Lesende einen zum Verständnis nötigen Background nicht hat.
Wobei GetlastBookedInvoice anders kommentiert werden muß als GetLastPosOfIn(Searchedstring,SourceString), falls überhaupt.

Gruß
K-H

[sakura]

Zitat von Stevie:

dass ich deiner Aussage, dass jeglicher Code, sei er noch so kurz, Kommentare aufweisen muss, nicht zustimme

Habe ich nicht geschrieben Ich schrieb Unit, und da ist nochmal ein Unterschied.

......

[a.def]

Zitat von Stevie:

Zitat von sakura:

Quellcode komplett ohne jegliche Kommentare ist aus meiner Sicht ein generelles No-Go, egal wie klein die Unit ist.

Und was genau soll man bei selbsterklärendem Code kommentieren?

Siehe auch: https://blog.codinghorror.com/coding-without-comments/

Schon mehrfach selbst erlebt:
Projekte auf Seite geschoben, nach Monaten wieder ausgegraben und schon gingen die Hände an den Kopf da ich den Code von damals nicht mehr verstanden habe.

[himitsu]

Zitat von sakura:

Wenn Luckies Aussage als "Blanket Statement" gemeint ist, dann:

Ich denke mal nicht.
Mr. Puff zieht doch niemals blank.

Als Hauseigenes IDE-Feature (seit 'ner Weile) hat Region zwar optiosch nichts herzumachen ... im Gegenteil, es ist schon ein bissl unsichtbar, gegen sowas wie die zuvielen =============.
Aber es hat den selben Vorteil, wie alles in klassen zu packen.

Regionen kann man zusammenfalten. Da sieht man zwar den Code nicht besser, aber den anderern Code kann man schön wegblenden.
Auch kann man Funktionen über mehrere Klassen zusammenfassen und hat dann über den Klassenbrowser oder die Struktur auch einen Überblick.
Oder man kombiniert gleich Beides.