Codedesign

[Luckie]

ja Moment. Ich hänge ihn mal an.

[negaH]

Zitat:

Was aber willst Du in Deinem Artikel darstellen?

Ich nahm an das Luckie über praktisches und gutes Codedesign referieren will. Gutes Codedesign berücksichtigt immer Erfahrungen von anderen Programmierern, und es ist ein Mix aus technischen Gegebenheiten des Compilers/Source Editierung/der Sprache und aus philosophischen Erwägungen wie Wartbarkeit/OOP/Algorithmen/Lesbarkeit/Dokumentation.

Wichtig ist das das Vorurteil das ein Source subjektiv und Geschacksache ist aus der Welt zu schaffen. Denn Programmierung ist reinste Logik und da haben Gefühle wie Geschmack nichts zu suchen. Man kann also ein gutes Code Design absolut logisch und schlüssig erklären warum es so am besten ist.

Eine der wichtigsten Regel ist es:
Der Programmierer codiert NICHT aus Selbstzweck und schon garnicht so das er sich in seinem Stil von allen anderen Programmierern unterscheidet !! Dies ist dumm und arrogant.

Delphi-Quellcode:

PROCEDURE _Tue_was_schlechter_stIEL(var
  param_1: XType);
     BEGIN
          IF BooleanVariable = TRUE
              THEN BEGIN
                  Display;
              END 
     END

Ist absolute Scheiße !

1.) Underline als Separator ist C/C++ Stil
2.) Underline am Anfang definiert virtuell einen Compiler Magic
3.) Compiler Tokens werden immer kleine geschrieben
4.) Blöcke werden niemals auseinander gerissen, wie beim obigen IF THEN
5.) begin end/try finally end/try except end definieren einen Block Anfang und End deshalb gehören sie auf selbe Einrückungsebene
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.
7.) Hinter JEDEM end gehört ein Semikolon, auch wenn es nicht unbedingt notwendig ist
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.


Gruß Hagen

[Luckie]

Prima. Unterhaltet euch nur schön weiter so, ich mache mir Notizen. Der Artikel oben ist übrigens erst mal nur ein grober Entwurf. Da muss auch sprachlich noch gefeilt werden, damit er sich flüssig liest.

@Hagen: Das geht aber schon in Richtung Codeformatierung, darüber wollte ich mich weniger auslassen. Dazu gibt es ja schon den Style Guide von Calvert.

[negaH]

Ein gutes Beispiel für relativ schlechten Code findet man in der INDY Library.
Ein gutes Beispiel für relativ guten Code findet man in der JEDI Library.

Gruß Hagen

[choose]

Hallo Luckie,

ich habe Deinen Text einmal überflogen und finde ihn ziemlich gut aufgemacht. Ähnlichen Code konnte ich bei vielen Einsteigern, die sich den Problemen nicht bewusst waren, ebenfalls entdecken.
Du zeigst recht pragmatisch, wovon andere Autoren in abstrakten Texten mit Realitätsfremden Diagrammen berichtet wird (bitte nicht missverstehen, ich bin ein Fan des MVC-Paradigmas!).

Hauptaugenmerk richtest Du nach meinem Empfinden auf Lesbarkeit, Verständnis und Änderung des Codes.
Was hältst Du von einem Folgeartikel, der Konzepte der Wiederverwendbarkeit aufzeigt? Ich könnte mir zB vorstellen, dass eine Person, die ähnliche Problemstellungen zu lösen versucht, Schwierigkeiten mit der Pflege und Übersicht den vielen ähnlichen Validierungsfunktionen begekommt...

[Luckie]

Zitat von choose:

ich habe Deinen Text einmal überflogen und finde ihn ziemlich gut aufgemacht.

Zitat:

Ähnlichen Code konnte ich bei vielen Einsteigern, die sich den Problemen nicht bewusst waren, ebenfalls entdecken.

Genau das ist die Zielgruppe. Deswegen will ich auch gar nicht so tief in die Materie einsteigen. Anfänger wären da einfach überforderet. Desweiteren kenn ich solche theoretischen Abhandlungen nicht und habe mich auch nicht damit beschäftigt. Ich bin eher der Praktiker.

Zitat:

Hauptaugenmerk richtest Du nach meinem Empfinden auf Lesbarkeit, Verständnis und Änderung des Codes.

Genau.

Zitat:

Was hältst Du von einem Folgeartikel, der Konzepte der Wiederverwendbarkeit aufzeigt? Ich könnte mir zB vorstellen, dass eine Person, die ähnliche Problemstellungen zu lösen versucht, Schwierigkeiten mit der Pflege und Übersicht den vielen ähnlichen Validierungsfunktionen begekommt...

Hm. Muss ich mal sehen. Aber ich hätte kein Problem damit auch Co-Autoren zu haben, falls interesse besteht, da mit zu wirken.

[negaH]

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

Delphi-Quellcode:

  if ((Boolean) and (not (Value = 1))) then Bad;
  if Boolean and (Value <> 1) then Good;

  if (A = 0) and (B = 0) and (C = 0) then Bad;
  if A or B or C = 0 then Good;

  if (A <> 0) or (B <> 0) or (C <> 0) then Bad;
  if A or B or C <> 0 then Good; // auch wenn dieser Code ineffizienter ist !
 
  if ((Red in Set) or (Green in Set) or (Blue in Set) or (Set = [])) and not (Yellow in Set) then Bad;
  if Set * [Red, Green, Blue, Yellow] <> [Yellow] then Good;

D.h. Boolsche Algebra heist das man mit den Operatoren AND,OR,NOT,XOR rechnen kann.
D.h. das man mit Mengen rechnen kann wie mit Boolscher Algebra.

Gruß Hagen

[Sharky]

Hai Hagen,

mache nur so weiter und zerstöre meine Illusion ist würde "gut" Coden

Ne, im Ernst: Wenn ich das hier mitlese wird mir bewusst auf was ich alles nicht geachtet habe.

Finde es allso Super!

Gerade die kurzen Beispiele zeigen sehr gut die Unterschiede zwichen gut und schlecht.

@Luckie: Auch das formatieren des Codes (inkl. der Namesvergabe von Methoden und Variablen) sollte nicht unerwähnt bleiben.

[Luckie]

Zitat von Sharky:

@Luckie: Auch das formatieren des Codes (inkl. der Namesvergabe von Methoden und Variablen) sollte nicht unerwähnt bleiben.

Ich verweise da auf den Style Guide von Charels Calvert, wie ich schon sagte.

[negaH]

@Luckie:

In deinem Tut:

1.) 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.
2.) ValidatDay() ist eine Schlampigkeit, denn das eine fehlende "e" für ValidateDay() hätte man auch noch schreiben können Es sei denn man würde IsValidDay() benutzen.
3.) Button1.Enabled := IsValidDay and IsValidMonth and IsvalidYear; stellt klip und klar eine Boolsche Berechnung dar. Man benötigt keinerlei if then else !
Selbiges in ValidatDay()
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
7.) Extended für die Berechnungen ist überdimensioniert, Default Floatingpoint sollte Double sein.
8.) CalcJulYear(Day, Month, Year: DWord): Extended -> CalcJulianYear(Year: Word; Month: Word = 1; Day: Word = 1): Word;
DWord ist ein Windows API Datentyp kein PASCAL Datentyp. In PASCAL wäre es Cardinal.

Gruß Hagen