Source-Code organisieren ...

[spectrumizer]

Hallo!

Ich wollt mal fragen, wie ihr es so managed, dass ihr bei größeren Projekten den Überblick über eure Sources behaltet? Also so, dass man auch noch nachvollziehen kann, was der Code macht, wenn man ihn sich nach ~ 1/2 Jahr mal wieder anschaut oder daran arbeitet ... ich verlier ihn nämlich Regelmäßig ab einer bestimmten Projektgröße und muss mich da irgendwie immer wieder rein- und durchwurschteln und da ich gerade ein Verwaltungsprogramm für einen eShop für eine Firma auf die Beine stelle, graust mirs jetz schon vorm Debuggen und späteren Warten und Erweitern des Sources.

Was haltet ihr von Struktogrammen (PAP) und wie / womit sollte man sie erstellen? Gibts dafür
Programme bzw. Faustregeln, wie man einen Source aufgliedern und strukturieren sollte? Wäre schön, wenn ihr ein bischen aus dem "Nähkästchen" plaudern könntet und eure Erfahrungen postet.

Grüße!

Mario

[Robert Marquardt]

Der Startpunkt ist ein strikter Code Style. Die Borland-Vorschriften sind wohlausgedacht und daher eine gute Wahl. Behandle Delphi wie eine case sensitive Sprace. Diese Regeln helfen den Code einfacher und schneller zu lesen.<br>
Kommentare sind <b>WICHTIG</b>! Dokumentation ist <b>NOCH WICHTIGER</b>!<br>
Bei den Kommentaren sei sparsam aber asusagekraeftig. Pro Funktion ein paar Zeilen und an kritischen Stellen auch etwas. Vermeide aussagelose Kommentare speziell so etwas "for I := 0 to Count-1 do // Iterate"

[Uwe Rupprecht]

Hi,

ich gliedere meine Funktionen, Klassen und Objekte nach Möglichkeit nach ihren Bereichen (Allgeimein,Datenbank,Oberfläche, Hilfsfunktionen usw..).

Desweiteren ist es Wichtig sprechende Namen für Funktionen, Klassen usw zu vergeben, auch wenn das mehr Tiparbeit bedeutet

[Hagen Reddmann]

@Uwe, korrekt DAS IST selbsterkärender Source der keiner Dokumenation bedarf. Man sollte den Source nicht als Program das eine Aufgabe erledigt betrachten, sondern als Dokumentation WIE man WAS macht. Ein guter Source sollte wie ein Lehrbuch zu lesen sein.<br>
Natürlich wird ein komplexes Projekt dann nicht ohne externe Doku auskommen, die dann die generelle Programlogik beschreiben sollte.<br>
Diese ist aber nicht so wichtig wie man vielleicht denkt. Sollte z.B. ein Projekt immer von den gleichen Codern gewartet werden dann sinkt deren Bedeutung. Wichtiger werden dann die "Dokus" über Fehler,Änderungen usw. IM Source selber.<br>

Gruß Hagen

PS: achso, bis zu einem gewissen Grad stört es nicht das man im Source die alte und deaktivierte Funktion belässt, nicht löscht und die neuere, verbesserte Funktion parallel im Source hat. Wie gesagt: bis zu einem gewissen Punkt