@Fritzew
Auf die Properties in den Klassen zu verzichten ist eine Überlegung wert.
Andererseits hat man mit den Properties auch einen kompletten Überblick über die Klassenmember innerhalb der Klassenmethoden.
Die Klassenunits verstecke ich mittlerweile regelmäßig hinter einer Factory, so dass ich auf der Projektlogik heraus ohnehin nur noch die Interfaces sehe.
Also ich werde die Properties weiter in den Klassen aufnehmen, könnte das aber optional auch ausschalten lassen.
Ist wohl eher Geschmacksache.
@Mavarik
Das Schieben von Gettern und Settern in Interfaces nach ganz oben finde ich gut. Werde ich so umsetzen.
(Im Grunde sollten die gar nicht geschrieben werden müssen und im Interface stehen. Ist ja ohnehin klar, wie die aussehen müssen.)
Die Properties selbst würde ich (wie oben beschrieben) eher mit in die Klassen übernehmen - optional abschaltbar.
Deine Einrückungen finde ich gewöhnungsbedürftig und bin noch unschlüssig, ob ich das gut finde oder nicht so gut.
Mich würde es stören, auf den Codeformatierer (von Delphi oder Third Party) verzichten zu müssen und das alles von Hand zurecht zu schieben. Wenn Du ein Property kürzer oder länger umbenennst wird das ja eine Schiebe-Orgie.
Aber ich kann mal schauen, ob ich eine solche Funktion mit unterbringen kann. Das Tool müsste halt hinter "function"-Deklarationen zwei Leerzeichen einfügen und bei gleichenartigen Zeilen untereinander bestimmte "virtuelle Tabs" benutzen.
Auch hatte ich schon mal überlegt, Code mit diesen Verkettungen (ich weiß gerade nicht wie man das nennt)
automatisch auszurichten, was Du immer mit den geschweiften Klammern machst.
Das würde mich ja rammdösig machen...
