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.