Codedesign

[choose]

Zitat:

Zitat von Negah

Es sollten niemals zu viele Klammern sein, sondern nur so viele wie nötig

Hallo Negah,

ich empfehle Einsteigern meißt eher das Gegenteil, weil vielen die Prioritätsregeln nicht "im Blut stecken".
Es gibt zwei Prioritätsregeln:

1. Punkt- vor Strichrechnung
2. Klammer vor allem

Lieber eine Klammer mehr, als ein Bug, den man nicht findet, weil man glaubt, der Compier übersetzt es so, wie man meint:

Delphi-Quellcode:

var 
  a, b: Integer;
begin
  a:= -1;
  b:=  2;
  if not a < b then

Und "Tricks mit binären Operatoren" in der Form

Zitat:

Zitat von Negah

Delphi-Quellcode:

  if A or B or C = 0 then Good;

würde ich als Einsteiger lesen als "Wenn eine der Variablen null ist, dann".

Ich hatte mal den folgenden Code gesehen:

Delphi-Quellcode:

  //its not a sony, its a trick
  a:= a xor b;
  b:= a xor b;
  a:= a xor b;

Sicher, er funktioniert, ist performat, braucht eine Variable weniger, aber: Wer, der nicht vorher ASM geschrieben hat, versteht ihn (und dann noch der Kommentar! Ich beziehe mich hier auf Negah: "Der Programmierer codiert NICHT aus Selbstzweck")?

[Luckie]

Schon verbessert. :thumb:

[negaH]

Delphi-Quellcode:

function IsValidDay(const Value: String): Boolean;
begin
  Result := StrToIntDef(Value, 0) in [1..31];
end;

function CalcJulianYear(Year: Word; Month: Word = 1; Day: Word = 1): Word;
begin
// falls CalcJulianYear eine "lowlevel" private Funktion ist
  Assert(Month in [1..12]);
  Assert(Day in [1..31]);
// falls CalcJulianYear eine "highlevel" globale Funktion ist
  if not (Month in [1..12]) then
    raise EConvertError.Create();
  if not (Day in [1..31]) then
    raise EConvertError.Create();
  
// hier die Berechnung aus der PDF, ich verstehe aber nicht was dort berechnet wird, 
// da die wichtigen Remarks fehlen !!?? :-)  
  
end;

Gruß hagen

[choose]

Hallo negaH,

Luckie hat bewusst darauf hingewiesen, dass der Article nicht in der finalen Version vorliegt.
Tippfehler, wie ein fehlender Buchstabe, sollten deshalb verziehen werden...

Zitat:

Zitat von negaH

die ShowMessage() sollte durch eine Excpetion ersetzt werden. Der Code als "Highlevel" Funktion sollte auch eine Fehlerüberprüfung haben. "Highlevel" Funktionen können demzufolge auch Exceptions auslösen. Paralell dazu könnte man die Funktion so umbasteln wie es in StrToIntDef() der Fall ist. Dies würde die Exceptions beseitigen und einen Default Wert zuweisen.

Assertion- und Exceptionhandling ist mehr als nur irgendeine Exception zu werfen. Weil die VCL es nur bedingt vorlebt und Delphi nicht das Konzept der Checked Exceptions unterstützt, sind sie dem Delphi-Einsteiger (Zielgruppe des Artikels) nicht vertraut. Richtig angewandt sind Exceptions sehr sinnvoll, aber auch aufwendig zu designen!

Zitat:

Zitat von negaH

4.) ALLE Varibalen beginnen mit Großbuchstaben !
5.) ValidatDay(d: string): Boolean; ist inkonsitent -> IsValidDay(const Value: String): Boolean;
6.) edtDay.Text -> EditDay.Text oder EDay.Text

Wenn Luckie sich auf den StyleGuide von Charles Calvert beruft, simmt das. Allerdings habe zu genau diesen Punkten schon häufiger Kritik vernommen...

Zitat:

Zitat von negaH

7.) Extended für die Berechnungen ist überdimensioniert, Default Floatingpoint sollte Double sein.

Auch hier würde ich lieber einen zu großen Datentyp (für einen Einsteiger) empfehlen als einen zu kleinen mit deaktivierte Bereichsüberprüfung (sonst sind 200d+100d plötzlich einmal 45d).

[negaH]

Zitat:

ich empfehle Einsteigern meißt eher das Gegenteil, weil vielen die Prioritätsregeln nicht "im Blut stecken".

Absolut falsch. Bei meinen Lehrlingen habe ich alle diese Regeln wieder und wieder in den Schädel gehämmert, denn wie soll man es richtig lernen wenn man es nicht richtig lernt ??
Jede Ausnahmeregel und Ausnahmevereinfachung führt dazu das man es so und nicht anders in Zukunft macht.

Einfach mal sagen das der Himmel Grün und die Wiese Blau ist, damit es ein Idiot versteht halte ich für falsch (überspitzt ausgedrückt :-) ) Dem Lernenden ist nicht geholfen dabei.

Delphi-Quellcode:

var
  a, b: Integer;
begin
  a:= -1;
  b:=  2;
  if not a < b then

Diese Abfrage muß logisch begriffen werden, man muß also Klamern setzen wenn man den Boolschen Vergleich if not (A < B) then erreichen will.
Wichtig ist es hier aber das man merkt das diese Abfrage absolut schlechter Stil ist und der Programmierer NICHT nachgedacht hat. Denn:

Delphi-Quellcode:

  if a >= b then ;

wäre die RICHTIGE Antwort !

Delphi-Quellcode:

  a:= a xor b;
  b:= a xor b;
  a:= a xor b;

Das sollte absolut vermieden werden, korrekt !
Eine zusätzliche Variable macht den Code lesbarer und ist unter umständen schneller.

Gruß Hagen

[Luckie]

So, das werde ich nachher mal alles zusammentragen und mit einfließen lassen.

[choose]

Cool. Postest Du hier noch einmal, wenn Du den Artikel fertig und auf Deiner Seite veröffentlicht hast?

Danke.

[Luckie]

Logisch, sonst macht es ja wenig Sinn. Ich muss mich nur irgendwie mit dem Autor für den schlechten Code einigen. Bis jetzt sperrt er sich noch. :cry:

[neolithos]

Zitat:

Zitat von Hagen

8.) if then erwartet eine Boolsche Abfrage, einen Boolean nochmals mit einer Boolschen Abfrage zu versehen deutet darauf hin das der Programmierer nicht rechnen kann und die Boolsche Algebra in der Schule verpennt hat.

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!

Man sollte aber einen Kommentar mit der Problembeschreibung dazusetzen.


Was bei mir noch immer aufgefallen ist,

Ich schreibe eine Procedure zuerst logisch auf.
Was soll grob getan werden. ==> Kommentare

Bsp: TSR

Delphi-Quellcode:

// Sortiere Feld
// Gehe Alle Städte -> Rekursion
for I := 0 to Count - 1 do
    // Schranke prüfen
    ;

Das Symikolon hatte ich vor sehr langer Zeit hinter das do gesetzt und manchmal vergessen es wieder wegzulöschen oder man setzt einen leeren Block.

Diese Vorgehensweise macht es mir leicht möglich das komplexen Problem in viele Teilprobleme zu zerlegen.

Nennt man glaube ich Top-Down-Prinzip.

[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. 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 :-)

Ich finde eure Ansätze bislang richtig gut, die machen Sinn und umfassen schon viele "Bereiche". Wenn sich daran hier im Forum jeder hält, haben wir alle mehr Spaß.

Bis dann,

S - tefano