Codedesign

[negaH]

Zitat:

Für komplizierte Ausdrücke verwende ich da meist ein Stück Papier und male ein KV-Tafel auf.
Damit kann man komplizierte abfragen vereinfachen!

Korrekt. Auch wenn man als Anfänger öfters mal das Hirn dabei verrenken muß, so wird man mit der Zeit ein Gefühl für die korrekten Ausdrücke entwicklen. D.h. man denkt nicht mehr darüber nach warum was wie besser ist. Dazu ist es aber notwendig das man von Anfang an als Anfänger immer über seinen Source nachdenkt und somit auch intensiver lernt. Eine Vereinfachungsmaßnahme die zwar durch zusätzliche Kommatas es einfacher verstehbar macht, hindert also am Denken und Lernen.

Du zB. nutzt KV-Tafeln, ich nutze einfache Grafiken da ich ein visuell geometrischer Denker bin.
Auf alle Fälle ist es wichtig dabei das man den Denkprozess durch mechanische Bewegungen wie das Schreiben enorm verbessert. (so wie Gestick, Mimick usw.)

Sich vor der korrekten Lösung eines Problemes zu drücken ist meiner Meinung nach nicht der richtige Weg. Übung macht den Meister :-)

Gruß Hagen

[MathiasSimmack]

@Hagen, erinnerst du dich noch an das Bool-Array:

Delphi-Quellcode:

const
  iRootKey : array[boolean]of cardinal =
    (HKEY_CURRENT_USER,HKEY_LOCAL_MACHINE);


{ ... }

if(RegOpenKeyEx(iRootKey[IsAdmin],
  'blablabla',
  0,
  KEY_READ or KEY_WRITE,
  reg) = ERROR_SUCCESS) then
try
  { ... }
finally
  RegCloseKey(reg);
end;

War ein Tipp von dir vor ... *puh* ... Jahren (?), weil ich neidisch auf die C-Programmierer und ihr

Code:

if(RegOpenKeyEx([color=#ff0000](IsAdmin)?HKEY_LOCAL_MACHINE:HKEY_CURRENT_USER[/color],
  [color=#000080]// ...[/color]

war. :) Und das hat mir im Laufe der Zeit doch einige if-Abfragen gespart. Macht sich auch gut beim Setzen von Flags (für Controls, usw.), die von bestimmten Bedingungen abhängig sein sollen.

Gruß.

[choose]

Zitat:

Zitat von MathiasSimmack

Macht sich auch gut beim Setzen von Flags (für Controls, usw.), die von bestimmten Bedingungen abhängig sein sollen.

Aber auch bei typisierten Ordinalwerten, zB

Delphi-Quellcode:

type
  TMyState = (msUnknown, msReady, msRunning, msDone);

function MyStateToString(const AState: TMyState): string;
const
  ArResult: array[TMyState] of string = ('Unbekannt', 'Bereit', 'Aktiv', 'Fertig');
begin
  Result:= ArResult[AState];
end;

Neben Übersichtlichkeit und Geschwindigkeit hat diese Variante gegenüber dem case-Statement den Vorteil, dass der Compiler die Anzahl der Elemente überprüft, also darauf hinweist, wenn nicht "jeder Fall bedacht" wurde.

Das ist iÜ eine der Möglichkeiten, die ich mit meinem Posting unter dem Punkt

Zitat:

Zitat von choose

Typesierte Ordinalwerte, um "selbstüberprüfende" Routinen zu schreiben (unbedachte Fälle vom Compiler "aufspüren" lassen)

meinte...

[neolithos]

Das ganze braucht man nicht auf Boolean's zu beschränken.

So kann man sich auch case n of's sparen

Delphi-Quellcode:

const
  ccHexAlpha : array[0..15] of char = '0123456789ABCDF';
...
  ccHexAlpha[dwWert and $F]

oder

Delphi-Quellcode:

type
  TFarben = (colBlack, colRed, colGreen, colWhite);

const
  csTexte : array [TFarbe] of String = ('Schwarz', 'Rot', 'Grün', 'White');

[neolithos]

Was mir dabei auffällt...

hatte wir schon die Notation erwähnt.

wie z.B.

i??? - Integer
s??? - String
l??? - Boolean
usw.

[choose]

Du meinst etwas in der Art der die Hungarian Notation?
Ich möchte micht hier wieder einmal auf den Style Guide beziehen

Zitat:

Zitat von Charles Calvert

Delphi is created in California, so we discourage the use of notation, except where required in header translations:

CORRECT
FMyString: string;

INCORRECT
lpstrMyString: string;

The exception to the Hungarian notation rule is in enumerated types.

[neolithos]

Zitat:

lpstrMyString: string;

Diese Art und Weise finde auch übertrieben, und zerstört mehr Informationen.

Zitat:

FMyString: string;

Das ist aber nach meinem Geschmack zu wenig Information. Deshalb bevorzuge ich bei String's das "s" nur Klassen erhalten ein "F" als Präfix.

Records das "r"
Pointer ein "p" + typen-präfix
z.B. Pointer auf einen Integer "pi"
Constanten "c" + typen-präfix
Übertragungsparameter "a" + typen-präfix

Das ist aber wahrscheinlich Ansichtsache.

[choose]

Hallo neolithos,

sicher kannst man mit ein wenig Gewöhnung mitunter schneller den Code verstehen, ohne die Deklarationen überprüfen zu müssen, aber was machst Du, wenn Du den Typen irgendwann änderst (zB von Record zu Klasse oder von Byte zu Integer zu Int64)? In diesem Fall müsstest Du das Interface Deiner Klassen bzw. die Deklarationen der Funktionen/Prozeduren nachträglich ändern, was bedeutet, dass Du ebenfalls in der Implementierung Anpassungen bei der Verwendung der Parameter vornehmen müsstest...

Luckie bestätigte, dass er sich bei seinem Artikel sowohl auf die Lesbarkeit als auch auf die Änderbarkeit des Codes konzentriert. Hier muss also abgewogen werden.
Im Hinblick auf die Zielgruppe des Artikels aber auch, weil es jede "individuelle" Notation zunächst zu erlernen gilt, würde ich mich persönlich gegen eine solche Notation aussprechen und mich in diesem Fall nach Charles Calvert richten.
Etwas anderes sind Suffixe bei Exemplaren oder Klassennamen, hier halte ich einen TFooVisitor oder eine TFooFactory für aussagekräftig und allgemein annerkannt.

[neolithos]

@choose
Ich geb dir recht auf die Zielgruppe bezogen ist es günstiger sowas zu vereinfachen.

Ich persönlich bleib dabei da es mir einfach Hilft schnell in alten Code von mir reinzukommen.

Und mit Änderungen hatt ich noch keine Probleme.
Da erstens sowas sellten vorkommt -> ich überlegt mir vorher was ich brauche
Und sollte es vorkommen geht es auch schnell von der Hand (selectieren, find&replace), dass klappt aber nur deshalb da ich so gut wie keine Globalen Variablen verwendet, die im ganzen Programm vorkommen.

Aber zum Schluß noch mal:

Ich geb dir recht auf die Zielgruppe bezogen.
-> damit es nicht zu mißverständnissen kommt.

[Luckie]

Zitat:

Zitat von S - tefano

Gibt es nicht von Borland selbst einen seitenlangen Artikel mit Richtlinien, wie man Pascal Code schreiben sollte? Ich bin mir sicher ich hab sowas schonmal gelesen, vielleicht weiß von euch ja einer wo es den gibt. Ich werd ihn mal suchen, den könnte man wenigstens noch als Vergleichsquelle benutzen, wenn man sich nicht komplett an ihn hält.

Du meinst den Style Guide von Charles Calvert. Findest du auf meiner Seite.

Zitat:

Denn neben den Regeln die es schon gibt noch eigene Regeln aufzustellen die denen ähnlich sind die es schon gibt...
Da kann ich mir auch ne eigene StVO entwerfen, die sich von der normalen nur dadurch unterscheidet dass ich immer Vorfahrt habe ;-)
Nichts für ungut :-)

1. Geht es da nur um die Codeformatierung. darum geht es mir aber gar nicht.
2. Saugen wir hier uns nicht irgendwas aus den Finger, wie es uns in den Kram passt, sondern das sind größtenteils eigne Erfahrungswerte, die sich über die Zeit als sinnvoll erwiesen haben. Dein Vergleich und deine Kritik ist alsi vollkommen fehl am Platz.

[Luckie]

Speziell an Hagen noch mal:

Du hast auf Seite 1 oder 2 folgende Aussagen gemacht:

in den Thread hats du folgende Aussagen getroffen:

• 3 ordinale Paramter maximal für Proceduren
• 2 ordinale Paramter maximal für Methoden (Self ist der 3. unsichtbare Parameter)
• register Aufrufkonvention wenn möglich
• Result immer nur am Ende der Funktion belegen, oder vor einem Exit;
• möglichst wenige lokale unkomplizierte Variablen
• das Aufsplitten komplexer Funktionen auf mehrere weniger komplexe Funktion macht den Code meistens schneller, da der Optimierer besser arbeiten kann (gilt auch für nested Proceduren)

Könntest du die mir bitte noch mal erleätern / begründen? Die Hintergründe hierzu wären nicht schlecht zu erfahren. Danke.

[Phoenix]

Zitat:

Zitat von negaH

6.) immer 2 Leerzeichen werden Blöcke eingerückt, nicht 3,4,5 oder 8 und schon garnicht Tabulatoren !! 2 Leerzeichen nichts anderes. Es kommt häufig vor das man einem PASCAL Source in anderen Editoren betrachten und Tabulatoren zerstören die Formatierungen.

Da muss ich Dir deutlichst(!) widersprechen. Diese Aussage ist inzwischen deutlichst veraltet, vo einigen Jahren hätte ich sie noch gelten lassen, heutzutage ist die aber überholt. Die einzige sinnvolle Formatierung für Einrückungen sind Tabulatoren.

Zur Begründung *g*:

Inzwischen ist jeder gängige Editor (SynEdit, UltraEdit, emacs, sogar vim, natürlich die Delphi-IDE und viele viele andere (Notepad sei hier mal ausgeschlossen)) bei der Darstellung der Tabs anpassbar.

Will heissen: Jeder Entwickler definiert für sich und für seinen Editor seine persönliche Einrückungstiefe, mit der Tabs dargestellt werden.

Wird nun für jede Einrückungsebene genau ein Tab verwendet, wird dies in jedem gängigen Editor korrekt und gleichmässig eingerückt angezeigt. Von Zerstörung der Formatierung kann hier gar keine Rede sein.

In dem Fall kannst Du also hergehen und Deine Einrückungsebene auf 2 Zeichen stellen, ich stelle meine auf 3 Zeichen, jeder hat seinen Code für ihn übersichtlich eingerückt und ich brauch mich nicht aufregen wenn ich von Dir nen Code bekomme, bei dem die Blöcke so eng aufeinandersitzen das man sie kaum unterscheiden kann bei nur 2 Zeichen :)

[Phoenix]

Zitat:

Zitat von neolithos

Records das "r"
Pointer ein "p" + typen-präfix
z.B. Pointer auf einen Integer "pi"
Constanten "c" + typen-präfix
Übertragungsparameter "a" + typen-präfix

Das ist aber wahrscheinlich Ansichtsache.

Japp. ;-)

Ich selber beschreibe nicht explizit, was das für ein Typ ist, sondern nur welchen Gültigkeitsbereich die Variable hat.

Code:

g_   global variables
a_   arguments   
l_   local variables
m_   member variables
i_   inline implementations

Inlines sollte man imho vermeiden, aber ab und kann man sie doch ganz gut gebrauchen.

Diese Notation hat den Vorteil, daß ich jederzeit im Code genau erkennen kann, woher eine Variable kommt. Wenn ich in einem Codestück ein a_FileName sehe, dann weiss ich, daß ich in der Argumentliste im Methodenkopf nachgucken wenn ich mich wundere warum da kein String drin ist. Wenn ich über ein g_forCounter stolpere weiss ich auch, daß sich der Entwickler keine Gedanken um sein Codedesign gemacht hat :)

Ausnahme von der Regel: i,j,s,t (die typischen lokalen Counter- und Stringvariablen halt) werden nicht mit l_ eingeleitet: l_i sieht bescheuert aus, und bei i weiss sowieso jeder das das ein Integer ist und wahrscheinlich als Schleifencounter verwendet wird.

[Chewie]

Zitat:

Zitat von Luckie

Speziell an Hagen noch mal:

Du hast auf Seite 1 oder 2 folgende Aussagen gemacht:

in den Thread hats du folgende Aussagen getroffen:

• 3 ordinale Paramter maximal für Proceduren
• 2 ordinale Paramter maximal für Methoden (Self ist der 3. unsichtbare Parameter)
• register Aufrufkonvention wenn möglich
• Result immer nur am Ende der Funktion belegen, oder vor einem Exit;
• möglichst wenige lokale unkomplizierte Variablen
• das Aufsplitten komplexer Funktionen auf mehrere weniger komplexe Funktion macht den Code meistens schneller, da der Optimierer besser arbeiten kann (gilt auch für nested Proceduren)

Könntest du die mir bitte noch mal erleätern / begründen? Die Hintergründe hierzu wären nicht schlecht zu erfahren. Danke.

*handheb* Wenn ich auch versuchen darf:

Zitat:

3 ordinale Paramter maximal für Proceduren

Es gibt 4 allgemeine CPU-Register: EAX, EBX, ECX und EDX. Eines davon, ich glaub EBX (oder ECX) wird vom Betriebssystem ständig verwendet, die anderen stehen dem Benutzer zur Verfügung. Wenn man nun die richtige Aufrufkonvention verwendet, nämlich register, werden so viele Parameter wie möglich in die Register geschrieben und nicht in den RAM (Stack). Bei max. 3 Parametern ist also alles im Register. Dazu ist noch zu sagen, dass es Ordinal-Typen sein sollen, oder, komplexen Dateitypen, Zeiger auf diese (deswegen auch const bzw. var). Denn in ein Register passen 4 Byte, aber kein 32-Byte-Record.
Registeraufrufe sind schneller, da Daten sowieso erst in Registern verarbeitet werden. Sind sie im Speicher, müssen sie erst in ein Register kopiert werden.

Beispiel:
(a sei Variable, also Speicheradresse)

Code:

ADD a, 10

ist eigentlich:

Code:

MOV EAX,a
ADD EAX,10
MOV a, EAX

Zitat:

2 ordinale Paramter maximal für Methoden (Self ist der 3. unsichtbare Parameter)

ergibt sich aus dem ersten, bei einer Methode wird immer ein dritter Parameter Self übergeben

Zitat:

Result immer nur am Ende der Funktion belegen, oder vor einem Exit;

Der Rückgabewert einer Funktion stehz am Ende in EAX. Wenn also nach dem Belegen des Rückgabewerts noch Aktionen ausgeführt werden, die das Regsiter EAX beanspruchen, wird das Result im Speicher abgelegt und muss am Ende in EAX kopiert werden.
Wird danach nix mehr gemacht, wird das Result sofort in EAX geschrieben und es muss nix mehr kopiert werden.

So, ich hoffe, das war soweit korrekt, aber den Rest sollte wirklich Hagen erklären ;-)

[Luckie]

Danköööö. :P

[Luckie]

So, habe mal etwas dran gearbeitet. Das letzte Kapitel "4. Auch die Werkzeuge muss man kennen" macht mir noch etwas Kummern. Es ist noch etwas mager. Wenn da noch jemand eine Idee hat, wie man das ergänzen und damit das ganze abrunden könnte, nur her damit. Sollten es größere Beiträge werden, ist natürlich auch eine Nennung als Co-Autor drin. Logisch. :wink:

Ich Depp, ich wollte es ja anhängen. :roll:

[negaH]

Zitat:

3 ordinale Paramter maximal für Proceduren
2 ordinale Paramter maximal für Methoden (Self ist der 3. unsichtbare Parameter)
register Aufrufkonvention wenn möglich

Bei der Aufrufkonvention "register" gelten folgende Regeln
1.) register ist die Standardaufrufkonvetion, wenn nicht explizit anderes deklariert wurde
2.) register über gibt die ersten 3 Parameter immer in den Registern EAX,EDX,ECX wenn der Parametertyp ordinal oder per Referenz auf einen Ordinalen Typ ist
3.) Methoden sind standardmäßig register deklariert
4.) Methoden nutzen als ersten odinalen Parameter den versteckten Parameter Self, somit haben wir nur noch die zwei Register EDX,ECX zur Verfügung
5.) bei Proceduren mit mehr als 3 oder aber Methoden mit mehr als 2 Parametern werden die restlichen Parameter auf dem Stack übergeben
6.) Fließkomma Paramater sind IMMER eine Ausnahme, sie werden nie in direkt in Registern übergeben, sondern immer by Reference
7.) Komplexe Rückgabe Paramater bei Funktionen werden ebenfalls als Referenz in den Stack Speicher als letzter Paramater übergeben. Darunter fallen zB. Records oder Interfaces oder ShortStrings, aber nicht LongStrings

Zitat:

Result immer nur am Ende der Funktion belegen, oder vor einem Exit;

Der Optimierer versucht als erste wichtige Maßnahme die häufigst benutzten lokalen ordinalen Variablen in Register zu optimieren. Sollten nicht genügend Register vorhanden sein um alle Lokale Variablen plus der ordinalen Resultat Variablen in Registern zu speichern, so gerät der Optimierer und Druck, eg. Zugzwang. Als erstes wird er das Resultat als temporäre lokale Variable anlegen. Beim Exit aus der Funktion wird dann dieser Inhalt in Register EAX kopiert. Ausnahme sind Fließkomma oder komplexe Datentypen.
Angenommen die Funktion nutzt nur sehr wenige lokale Variablen, es stehen also genügend freie Register zur Verfügung. Wird nun denoch Result sofort in der Funktion benutzt, statt eben erst ganz ganz zum Schluß so wird der Optimier ein Register benutzt das NICHT EAX ist. Erst am Schluß wird er das benutzte Register, meistens ESI,EDI,EBX in das EAX Register kopieren. Dies bedeutet das wenn man das Resultat in eine selbstdefinierte lokale Variable berechnet und erst ganz zum Schluß Result := LokaleVariable setzt der Optimier nun Freiheiten gewinnt. Er kann also selbständig entscheiden wie und wo er diese Lokale Vaiable in welches Register optimiert. So oder so wird er am Exit der Funktion ein MOV EAX,reg durchführen.
Hintergund bei dieser Logik ist der Fakt das nachdem Resultat am Anfeng gesetzt wurde nun Aufrufe zu Unterproceduren erfolgen können. Er darf also NICHT EAX sofort als Resultat Register bentzen, da ja durch den Unteraufruf EAX,EDX,ECX jederzeit zerstört werden können. Desweiteren ist die Standardaufrufkonvention ja register, also EAX,EDX,ECX könnten bei Unterfunktionen als Paramater dienen. Nun, statt wie in C/C++ aufwendige Analysen durchzuführen haben die Borlandianer anders gedacht. Sie benutzen die Regel das EAX,EDX,ECX jederzeit zerstörbar sind und ESi,EDI,EBX immer innerhalb von Unterfunktionen durch diese gesichert werden müssen. Somit können die Register ESI,EDI,EBX ohne weitere Source-Analyse als Register-Lokale-Varibalen benutzt werden. Statt also wie in C/C++ auf alle Eventualitäten durch komplette Live-Analyse des gesammten Source zu optimieren, wie beim Borland Compiler von vornherein mit einem Regelwerk gearbeitet. Der Optimierer optimiert so als wäre es im Scheiß egal welche Unterfunktionen noch im Source stehen.
Nun, wird Result schon am Anfang der Procedure gesetzt so MUSS der Optimierer diesen Wert als unsichtbare temporäre lokale Variable auf dem Stack verwalten.

Zitat:

möglichst wenige lokale unkomplizierte Variablen
das Aufsplitten komplexer Funktionen auf mehrere weniger komplexe Funktion macht den Code meistens schneller, da der Optimierer besser arbeiten kann (gilt auch für nested Proceduren)

Auch bei diesen Tipps geht es darum dem Optimierer den Registerdruck zu nehmen, bzw. eben die Entscheidungs/Optimierungsfreiheiten zu erhöhen. Der Delphi Optimierer sieht das Innere einer Funktion als eigenständige und kleinste Optimierungseinheit an, bzw. BlackBox. Er weiß das EAX,EDX,ECX frei benutzt werden dürfen, das EDI,ESI nach deren Sicherung auf dem Stack frei benutzt werden können, und das EBX abhänig ob man Kylix Code erzeugt oder nicht ebenfalls nach der Sicherung auf dem Stack benutzt werden kann. Außnahme bei EBX sind nested Funktions. Bei solchen Funktionen wird der Compiler EBX als indirekten Stack-Pointer-Index benutzen um auf den übergeordneten Stack zuzugreifen. Allerdings NUR wenn in der nested Funktion auch wirklich Code steht der auf übergeordnete Variablen zugreift.

Nun, als erstes wird der Optimierer abhänig von der Komplexität entscheiden ob er die Übergabeparameter der Funktion zwischenspeichern muß. Wenn NICHT das entsteht die optimialste Form einer Funktion. Input über EAX,EDX,ECX, Berechnung nur mit EAX,EDX,ECX und Rückgabe über EAX. Falls aber Lokale Variablen existieren und Registerdruck ermittelt wird wird der Optimierer an´fangen ESI,EDI und eventuell EBX auf den Stack zu sichern. Danach werden die Paramater in EAX,EDX,ECX ind ESI,EDI kopiert. Dies trifft zB. fast immer bei Methoden zu, d.h. Self in EAX landet am Anfang der Methode in ESI. Das wird gemacht damit eventuelle Unterproceduren und methoden die wiederum Self benötigen OHNE Stackzugriffe über ESI Self zur Verfügung haben. Vor dem Aufruf einer solchen Unter-Methode wird der Compiler also ESI wieder nach EAX kopieren. Bei zB. 5 solcher Aufrufe würde er als 1. ESI pushen, 2. ESI=EAX setzen, 3. dann 5 mal EAX=ESI setzen und die Untermethoden aufrufen. Dies kommt mit 2 Stackzugriffen aus zum Pushen und Poppen von ESI. Würde man Self im Stack speichern so müsste der Compiler vor jedem Aufruf der 5 Untermethoden einen Stackzugriff durchführen um EAX korrekt zu laden.
Steigt die Komplexität der Funktion/Methode weiter an, so wird der Compiler die Taktik ändern. Er betrachten Schleifen als eigenständige Blacboxes und versucht nun inerhalb der Schleifen die Register gut zu nutzen. Z.b. preferiert er als Zählvaribale ein Register plus ein Register als Zeiger auf die Daten plus ein Register als Datenkontainer. Innerhalb der Schleife wird er nun per indirekter Addressierung mit Hilfe der Zählvaribalen im Register die daten in das Datenregister laden.


Gruß Hagen

[Luckie]

Puh, ich erlaube mir das mal so zu übernehmen. Ich glaube, besser kann man es nicht erklären.

[negaH]

Naja, die Fehler in der Rechtschreibung sollten entfernt werden.

Ach wichtig ist auch noch folgende Information. Der Optimierer hat in keienr Delphi version einen Algortihmus zur Entfernung redundanter Register-Inhalte. Angenommen vor einem Unter-Methoden-Aufruf lädt der EAX aus ESI/EDI oder Stack. Danach ruft er die 1. Untermethode auf die NICHT EAX modifieziert. Nun beim nächsten Aufruf der 2. Untermethode wird er wiederum EAX aus ESI/EDI/Stack laden, obwohl EAX eigentlich schon Self enthält.

Dies ist absolut logisch das der Borland Compiler/Optimier NIEMALS Procedure/Funkction/Methoden übergreifen optimiert. Dies steht im Gegensatz zum C/C++ Compiler.

Wie immer gibt es sehr viele Ausnahmen, zB. eben die Fließkomma Berechnungen und deren Paramater. Das komplette Fließkommahandling des Optimierers muß vollständig losgelösst vom Rest des Optimierers betrachtet werden. In Punkto Fließkomma-Optimierung gilt nur eine einzigste Aussage über den Optimierer = er existiert NICHT, d.h. Fließkomma-Opertionen werden so gur wie überhaupt nicht optimiert !

Gruß Hagen

[Luckie]

Zitat:

Zitat von negaH

Naja, die Fehler in der Rechtschreibung sollten entfernt werden.

Schon geschehen. :wink: