Neuer Artikel auf meiner HP: "Code-Design"

[Luckie]

Ja eigentlich sollte es ein Tutorial werden, aber da bin ich einfach nicht mit zu Potte gekommen, ergo habe ich es kurzer Hand als Artikel veröffentlicht.

Link: CodeDesign

[edit=Matze]Link aktualisiert. MfG, Matze[/edit]

[MathiasSimmack]

Zitat:

Zitat von Luckie

Ja eigentlich sollte es ein Tutorial werden, [...]

Ein Tutorial? Nee, ein Artikel ist vollkommen ausreichend ...

Zitat:

[...] aber da bin ich einfach nicht mit zu Potte gekommen, ergo habe ich es kurzer Hand als Artikel veröffentlicht.

*hüstel* Trotz neuer Rechtschreibung ist "kurzerhand" immer noch ein Wort. Aber irgendwie kommt mir der Artikel bekannt vor. ´s sind auch noch die selben kleinen Tippbugs drin. ;)

Zitat:

Was unterscheidet guten Code von schlechten Code?

Na? Na? Wer weiß es? Ich meine, wo liegt hier der Fehler im Satzbau?

[mirage228]

Zitat:

Zitat von MathiasSimmack

Zitat:

Was unterscheidet guten Code von schlechten Code?

Na? Na? Wer weiß es? Ich meine, wo liegt hier der Fehler im Satzbau?

Also, ich würde mal sagen:

• Das erste "Code" müsste / könnte weg.
• Es müsste außerdem noch "von schlechtem" heißen.

Ich hoffe das war jetzt alles richtig ;)

mfG
mirage228

[Stevie]

Und ich dachte immer, mein Code wäre schon gut designed. Aber das würde mir Luckie wahrscheinlich nur um die Ohren hauen. :wall:
Naja, ich werd's versuchen, ab jetzt besser zu machen.

Hey, und das mit dem SetWindowLong ist für mich auch neu, aber echt nützlich.
Wieso haben die von Borland das nicht mit in ihre TEdit.CharCase oder ne andere Property mitaufgenommen!? :gruebel:

Also, weiter so, Luckie!!! :thuimb:

[Fellmer Lloyd]

Hi Luckie.

Du schreibst i deinem Artikel, die "Ungarische Notation" seie überflüssig.
Darf ich dich fragen wie du deine Variablen in einer Klasse Deklarierst?
Ich dachte immer das in dem Falle ein "F" vor der Variable stehen sollte.

Jetzt bin ich aber nicht mehr sicher :roll:

[mirage228]

Zitat:

Zitat von Fellmer Lloyd

Hi Luckie.
Ich dachte immer das in dem Falle ein "F" vor der Variable stehen sollte.

Jetzt bin ich aber nicht mehr sicher :roll:

Hi,

ich schreibe vor die privaten Variablen immer ein "F". Bei den Properties, die auf die private Variable zugreifen, lasse ich das "F" weg.

"F" steht hier übrigens für "Field" ;)

mfG
mirage228

[Sanchez]

Das Präfix-F für Member-Variablen kommt nicht aus der ungarischen Notation sondern aus dem Borland Stylguide, den du übrigens auch auf Luckie's HP findest. Die ungarische Notation ist da um einiges Umfangreicher.

grüße, daniel

[mschaefer]

Moin, moin Lucky,

denke da liese sich wirklich mehr draus machen. Alleine bleibt man häufig nach so einzelnen Kapiteln stecken. Codedesign und Aufgabenaufteilung gibt das schon gut wieder (auf die Änderung der neuen Rechtschreibereform warte ich ehedem schon wieder).

Aber wenn ich unter Zeitdruck programmiere, dann bleibt schon mal die Formatierung auf der Strecke. Eigentlich bräuchte die IDE einen automatischen Nachformatierer, der Anspringt wenn die Routine abgeschlossen ist. Das mit dem Codedesign läuft häufig im zweiten Durchlauf. Dabei gibt es eigentlich ein Hausverbot für Proceduren die länger als eine Bildschirmseite sind...

Grüße // Martin

[Luckie]

Zitat:

Zitat von mschaefer

Eigentlich bräuchte die IDE einen automatischen Nachformatierer,

Gibt es doch als Experten: delforexp.

[Fellmer Lloyd]

[quote="mirage228"]

Zitat:

Zitat von Fellmer Lloyd

ich schreibe vor die privaten Variablen immer ein "F". Bei den Properties, die auf die private Variable zugreifen, lasse ich das "F" weg.

"F" steht hier übrigens für "Field" ;)

So mache ich es auch.
Ich werde mir jetzt die Borland Stylguide vornehmen.

Danke.

[mschaefer]

Da werfe ich in der Pause gleich mal eine Blick drauf !

Grüße // Martin

[GuenterS]

es gibt da einen guten Quellcodeformatierer

downloadbar auf folgender Adresse

http://www.dow.wau.nl/aew/DelForExp.html

[Stevie]

Zitat:

Zitat von Luckie

Gibt es doch als Experten: delforexp.

Die Formatierung ist damit schonmal kein Problem mehr, wir benutzen das auch in der Firma.

[phlux]

Und wer findet den Rechtschreibfehler in der Überschrift des Threads? :mrgreen:
Öhm gabs den Artikel nicht schon auf deiner Seite Luckie?? :gruebel:

[Fellmer Lloyd]

Ich habe noch zwei Fragen bezüglich der Borland Styleguide.
Es sind Peanuts, aber man will ja alles richtig machen :wink:

1. Vergleichs- und Zuweisungsoperanden

Delphi-Quellcode:

if x=0 then //Steht in meiner Delphi-Bibel
if x = 0 then //Styleguide

x:= 0 //Bibel
x := 0 //Guide

2. "if-then" Zeilenumbruch

Delphi-Quellcode:

if x=0 then DoSomething; //Finde ich eigentlich übersichtlicher
if x=0 then
  DoSomething; //Gemäss Styleguide

Welche Möglichkeiten sind zu bevorzugen?

Gruss Fellmer

[mirage228]

Hi,

ich mache es eigentlich immer so, wie es im Styleguide steht.

mfG
mirage228

[Tortus]

Zitat:

Zitat von Fellmer Lloyd

Welche Möglichkeiten sind zu bevorzugen?

Immer die Möglichkeit, die dir selber am meisten liegt. Was bringt dir ein Quelltext, der dem Styleguide folgt, in dem du dich aber selber nicht zurechtfindest

[Fellmer Lloyd]

[quote="Tortus"]

Zitat:

Zitat von Fellmer Lloyd

Was bringt dir ein Quelltext, der dem Styleguide folgt, in dem du dich aber selber nicht zurechtfindest

Ich bin dynamisch, d.h. in 2 bis 3 Monaten hab ich mich umgewöhnt wenns sein muss.

[Phoenix]

Zitat:

Zitat von Fellmer

Welche Möglichkeiten sind zu bevorzugen?

Delphi-Quellcode:

if x = 0 then
   DoSomething;

Die hier. Genauso wie folgende Konstrukte:

Delphi-Quellcode:

   if x = y then
      // blafasel
   else if y = z then begin
      // blubb
   end
   else begin
      // dumdidum
   end;

Das else immer in eine neue Zeile, weil möglicherweise davor ein etwas längerer Kommentar stehen könnte. Stünde das if dann auf einer neuen Zeile für sich wäre man meist verloren weil man nicht mehr erkennt, das es zu dem else irgendwo vor dem Kommentar gehört.

Edit: delphi-tags korrigiert. :)

[neolithos]

Delphi-Quellcode:

   if x = y then
      // Eine Anweisung
   else if y = z then 
      begin
        // mehrer Anweisungen
      end
   else 
      begin
        // mehrer Anweisungen
      end;

[Luckie]

Delphi-Quellcode:

if x = y then 
  // Eine Anweisung 
else if y = z then 
begin 
  // mehrer Anweisungen 
end 
else 
begin 
  // mehrer Anweisungen 
end;

[mirage228]

Zitat:

Zitat von Luckie

Delphi-Quellcode:

if x = y then 
  // Eine Anweisung 
else if y = z then 
begin 
  // mehrer Anweisungen 
end 
else 
begin 
  // mehrer Anweisungen 
end;

Ganz genau so mache ich es auch.

mfG
mirage228

[Sanchez]

Ich machs immer so:

Delphi-Quellcode:

  if x = y then begin
    // Eine Anweisung
  end else if y = z then begin
    // mehrer Anweisungen
  end else begin
    // mehrer Anweisungen
  end;

Ich finds so kompakter und übersichtlicher. Außerdem ists bei uns Firmenstandard.

[Fellmer Lloyd]

Ich werde mich in Zukunft nach dem Stil von Luckie und mirage richten.

Danke nochmals :thuimb:

[neolithos]

Ich habe mich für meine Variante entschieden, da Sie den Augenzukneif-Test bestanden hat. Bei den anderen sehe ich so schlechte die Programm-Struktur. Und um die Struktur geht es ja bei der Strukturierenden Programmierung.

Das ist deshalb quasi in der Firma wo ich arbeite Firmenstandard.

[Chewie]

Interessant, bei mir sähe das so aus:

Delphi-Quellcode:

//evtl. Kommentar was abgefragt wird
if x = y then 
  // Eine Anweisung 
else
//evtl. Kommentar was abgefragt wird
if y = z then 
begin 
  // mehrer Anweisungen 
end 
else 
//evtl. Kommentar was sonst passiert
begin 
  // mehrer Anweisungen 
end;

[Meflin]

wie du schon schreibst ist codeformatierung hauptsache geschmackssache. und solange nur der autor selbst sich im code auskennen muss, kann er auch alles in eine zeile quetschen wenn es ihm (oder ihr) spass macht. dein artikel ist also wohl hauptsächlich für angehende opensource programmierer. aber trotzdem, wundert mich wie zu sonem thema so viel rausquetschen kannst ;-)

[Alfons_G]

Bei uns sieht's üblicherweise so aus:

Delphi-Quellcode:

//
//  Einleitender Kommentar zu dieser Routine (falls erforderlich)
//

if x = y then
  begin 
  // Eine Anweisung
end 
else if y = z then 
  begin 
  // mehrere Anweisungen 
end 
else 
  begin 
  // mehrere Anweisungen 
end; 

//
//  Nächste Routine ...

Einzelne Anweisungen ohne begin ... end mache ich eigentlich nur bei Debug-Anweisungen, die wieder rausgenommen, bzw. auskommentiert werden. Falls hinter der Bedingung irgendwann weitere Anweisungen kommen, kann man so nervige Fehler vermeiden.

:coder:

[mirage228]

Zitat:

Zitat von Alfons_G

Bei uns sieht's üblicherweise so aus:

Delphi-Quellcode:

//
//  Einleitender Kommentar zu dieser Routine (falls erforderlich)
//

if x = y then
  begin 
  // Eine Anweisung
end 
else if y = z then 
  begin 
  // mehrere Anweisungen 
end 
else 
  begin 
  // mehrere Anweisungen 
end; 

//
//  Nächste Routine ...

Einzelne Anweisungen ohne begin ... end mache ich eigentlich nur bei Debug-Anweisungen, die wieder rausgenommen, bzw. auskommentiert werden. Falls hinter der Bedingung irgendwann weitere Anweisungen kommen, kann man so nervige Fehler vermeiden.

:coder:

Hi,

was ich nachteilig bei deinem Style finde, ist, dass man nicht genau sagen kann, welches end zu welchem begin gehört.
Das kann manchmal unpraktisch sein...

mfG
mirage228

[DP-Maintenance]

Dieses Thema wurde von "Daniel" von "Programmieren allgemein" nach "Tutorials und Kurse" verschoben.
Tutorial hin, Artikel her - es passt eindeutig besser in die Rubrik "Tutorials".

[BKempf]

Wenn ich ein "end" sehe, suche ich dazu automatisch das "begin".
Ich habe mal eine Weile mit

Delphi-Quellcode:

if eins then begin
  foo;
end else if zwei then begin
  bar;
end else begin
  blubb;
end;

und aehnlichen Dingern experimentiert. Das ist fuerchterlich schiefgegangen, weil ich meine Bloecke nicht durch Draufsehen erkennen konnte, sondern immer das Ende der Zeile suchen musste. So etwas zu debuggen hat ewig gedauert.


Mein persoenlicher Styleguide sagt jetzt:
- Nach einem then folgt immer ein begin/end-Block. Ausnahmen, wenn ueberhaupt, nur zum Debuggen und dann mit (**) gekennzeichnet (das ist mein Zeichen fuer Baustellen, da ich als echte Kommentare nur die beiden anderen Typen verwende).
- Auch vor einem "end" steht ein Semikolon, ob ueberfluessig oder nicht. Es koennten ja noch Anweisungen hinzugefuegt werden, und dann ist dafuer schon alles vorbereitet :-). Sieht ausserdem einheitlicher aus.
- "begin" und "end" ("case xy of" und das dazugehoerige "end", "record"/"end", ...) beginnen grundsaetzlich auf einer Spaltenebene, die vom IDE-Editor mit einer ungeraden Zahl bedacht wurde.
- "else" steht auf geraden Ebenen. Das trennt mehrere aufeinanderfolgende begin..end-Bloecke optisch ein wenig.
- Bei mehreren if-Abfragen (quasi "case of" mit komplexeren Abfragen, die ein einfaches echtes "Case of" verhindern, etwa Stringueberpruefungen) stehen alle "if" in derselben Spalte.

Delphi-Quellcode:

// (Die Unterstriche bitte einfach mal wegdenken)
if eins then
begin
  foo;
end
_else
if zwei then
begin
  bar;
end
_else
begin
  blubb;
end;

Das ist zwar nicht so schoen kompakt wie andere Varianten, aber ich finds uebersichtlicher und das faellt ohnehin nicht sehr ins Gewicht, weil ich grosszuegig Leerzeilen einstreue.

[GuenterS]

Ich habe die Unterstriche mal weggemacht, dann sieht man gleich besser wie Du es gemeint hast. Frag mich wieso hast Du sie überhaupt dazu gegeben?

Delphi-Quellcode:

if eins then 
begin 
  foo; 
end 
else 
if zwei then 
begin 
  bar; 
end 
else 
begin 
  blubb; 
end;

Ich selbst bevorzuge aber so einen etas anderen Stil. Finde ich um einiges kompakter.

Delphi-Quellcode:

if eins then 
  foo
else if zwei then 
  bar 
else 
  blubb;

[Die Muhkuh]

Ich bevorzuge den Style von BKempf:

Delphi-Quellcode:

if a = b then
begin
  blubb;
end
else
begin
  >(((°>;
end;
if b = c then
begin
  ...;
end
else
begin 
  ..;
end;

[edit=Sharky]Delphi-Abschluss-Tag gesetzt ;-) Mfg, Sharky[/edit]

[BKempf]

Zitat:

Zitat von GuenterS

Ich habe die Unterstriche mal weggemacht, dann sieht man gleich besser wie Du es gemeint hast. Frag mich wieso hast Du sie überhaupt dazu gegeben?

Delphi-Quellcode:

if eins then 
begin 
  foo; 
end 
 else 
if zwei then 
begin 
  bar; 
end 
 else 
begin 
  blubb; 
end;

Ich habe mich unklar ausgedrueckt. Die Unterstriche sollten zwar weg, aber der Platz sollte stattdessen von je einem Leerzeichen besetzt werden, d.h. die else-Anweisungen sollten um 1 eingerueckt bleiben :-).
Irgendwie hatte ich den Eindruck, als wuerden einzelne Leerzeichen auf dem Weg vom Browser ins Forum abhanden kommen ;-), jedenfalls waren die Einrueckungen in der Vorschau auf wundersame Weise verschwunden. Da habe ich mit halt mit Unterstrichen geholfen.

Zitat:

Zitat von GuenterS

Ich selbst bevorzuge aber so einen etas anderen Stil. Finde ich um einiges kompakter.

Delphi-Quellcode:

if eins then 
  foo
else if zwei then 
  bar 
else 
  blubb;

Den verwende ich nicht, weil dabei die Bedingungen nicht genau untereinander stehen. Abgesehen davon schreibe ich ja fast immer komplette begin..end-Bloecke, auch da, wo nur eine Anweisung bedingt ausgefuehrt werden soll.

[GuenterS]

Zitat:

Zitat von BKempf

Zitat:

Zitat von GuenterS

Ich habe die Unterstriche mal weggemacht, dann sieht man gleich besser wie Du es gemeint hast. Frag mich wieso hast Du sie überhaupt dazu gegeben?

Delphi-Quellcode:

if eins then 
begin 
  foo; 
end 
 else 
if zwei then 
begin 
  bar; 
end 
 else 
begin 
  blubb; 
end;

Ich habe mich unklar ausgedrueckt. Die Unterstriche sollten zwar weg, aber der Platz sollte stattdessen von je einem Leerzeichen besetzt werden, d.h. die else-Anweisungen sollten um 1 eingerueckt bleiben :-).
Irgendwie hatte ich den Eindruck, als wuerden einzelne Leerzeichen auf dem Weg vom Browser ins Forum abhanden kommen ;-), jedenfalls waren die Einrueckungen in der Vorschau auf wundersame Weise verschwunden. Da habe ich mit halt mit Unterstrichen geholfen.

Zitat:

Zitat von GuenterS

Ich selbst bevorzuge aber so einen etas anderen Stil. Finde ich um einiges kompakter.

Delphi-Quellcode:

if eins then 
  foo
else if zwei then 
  bar 
else 
  blubb;

Den verwende ich nicht, weil dabei die Bedingungen nicht genau untereinander stehen. Abgesehen davon schreibe ich ja fast immer komplette begin..end-Bloecke, auch da, wo nur eine Anweisung bedingt ausgefuehrt werden soll.

Achso hast Du das gemeint, naja dann find ich Deinen Stil für mich selbst eben noch ungünstiger weil ich dann erst nach dem zugehörigen else suchen muss und es zudem ja auch nicht dem Borland Stil entspricht. Aber jeder wie er glaubt.

[BKempf]

Zitat:

Zitat von GuenterS

Achso hast Du das gemeint, naja dann find ich Deinen Stil für mich selbst eben noch ungünstiger weil ich dann erst nach dem zugehörigen else suchen muss und es zudem ja auch nicht dem Borland Stil entspricht. Aber jeder wie er glaubt.

Fuer mich ist das optimal :-).
Abgesehen davon, dass ich die elses selten suche (und wenn, dann halt nur zwischen den eigentlichen Hauptebenen suchen muss), sind mir von der Struktur her die begin...end-Bloecke wichtiger, da sie haeufiger vorkommen (und auch, weil diese Strategie problemlos auf aehnliche Strukturen wie record...end, repeat...until etc. uebertragbar ist).

[mimi]

was haltet ihr von diesem code(es ist aus meinem pac-man clone und ist in einer extern unit in einer eigenen klassse ausgelagert und die komponenten(DXDraw, DXTimer, DXListImage werden zurlaufzeit erstellt)

Code:

procedure TPACMan.DXDraw1MouseDown(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
var
  i,index:Integer;
  k:array of TKI;
begin

  if ssLeft in Shift then begin
    if (x div mapS <= MapX) and (y div mapS <= MapY) then begin 
      if NTyp = isStein then CreateItems((x div MapS),(y div MapS),nTyp,ntex);
      if NTyp = isKi then CreateKI( (x div mapS),(y div mapS),0,0,random(6)+3 );
      if NTYp = isPlayer then begin
        Player.x:=x div mapS;
        Player.y:=y div mapS;
      end;
    end;
  end;

  if ssRight in Shift then begin
    if NTYp = isStein then begin
      Map[x div MapS,y div MapS].Typ:=None;
      Map[x div MapS,y div MapS].Tex:=0;
    end;

    if NTYp = isKI then begin
      index:=0;

      for i:=0 to HIGH(ki) do begin
        if (ki[i].x = x div mapX) and (ki[i].y = y div mapY) then begin
          index:=i;
          break;
        end;
      end;

      for i:=0 to HIGH(KI) do begin
        if i <> index then begin
          SetLength(k,high(k)+2);
          k[HIGH(K)]:=ki[i];
        end;
      end;

      SetLength(ki,0);
      SetLength(ki,high(k));

      for i:=0 to HIGH(KI) do begin
        ki[i]:=k[i];
      end;

    end;
  end;
        
end;

ich finde so einen code viel übersichtlich als, wenn man z.b.

Code:

for i:=0 to high(ki) do 
begin
...
end;

schreiben würde

[MathiasSimmack]

Das habe ich auch mal gedacht, aber letztlich kommt es auf´s selbe raus. Ich meine, das "if" leitet die untergeordnete Ebene im Prinzip ja ein, da spielt´s dann auch keine Rolle mehr, das "begin" auf die gleiche Höhe zu setzen. Dem Compiler macht das nichts aus; will sagen: das Ergebnis ist das gleiche.

Soll heißen: Ich bevorzuge mittlerweile dann doch den Stil

Delphi-Quellcode:

if(irgendwas) then
begin
  irgendwas_anderes;
end;

Speziell auch wenn es um sehr lange Zeilen geht, mache ich lieber in der nächsten Zeile weiter als den rechten Rand im Editor zu überschreiten. Das mag den Code optisch verlängern (weil man mehr scrollen muss), aber andere Nebenwirkungen hat es nicht.

[mimi]

wenn ich z.b. mehre blöcke hintereinander habe die mit begin anfangen und end aufhören komme ich immer ducheinander, wenn das begin nicht auf der gleichen zeile steht wie der block *G*

naja, es ja auch egal *G*

[MathiasSimmack]

Das sehe ich zwar anders, aber wenn es dir egal ist, warum fragst du dann überhaupt?