Die "richtige" Sourcecode Formatierung?

[Neutral General]

Zitat von Jumpy:

Ich dachte immer das end gehört zum begin (ausser beim try) und drum schreibe ich es auch auf eine Ebene.

Ein end gehört IMMER zu einem begin. Man kann es auch so sehen, dass nach einem then generell nur eine Anweisung stehen kann. Und begin/end ist eine Anweisung (die als Container für mehrere Anweisungen dient). begin-end kann auch komplett ohne if/for/while o.ä. im Code stehen. Sieht zwar seltsam aus, aber ist erlaubt und zeigt umso mehr, dass ein end immer zu einem begin gehört.

[nahpets]

Zitat von SProske:

Zitat von nahpets:

Delphi-Quellcode:

// Folgt auf ein If nur eine Anweisung, dann wird das ein Einzeiler, solange er nicht über ca. 80 Zeichen hinaus geht.
if ... then ...;

Und wenn du mal einen Haltepunkt auf die Anweisung setzen willst, ärgerst du dich über diese Anordnung und verteilst es wieder auf 2 Zeilen - richtig?

Das ich den Debugger benötige kommt so selten vor, dass ich damit leben kann. Und wenn, dann kommt der Haltepunkt auf die Zeile mit dem If, dann kann ich direkt sehen, was denn da so in den abzufragenden Variabeln der IF-Anweisung steht.

Den Debugger brauche ich fast nur, um bei einem Fehler, den ich nicht finde, die IDE beim Auftreten des Fehlers mir die Stelle zeigen zu lassen, an der der Fehler auftritt.

Keine Ahnung, was ich "falsch" mache, aber der Debugger ist bei mir das Teil, dass ich am wenigsten nutze

Eventuell liegt es auch daran, dass ich Programme immer mit Debuginfos und Map-Datei erstelle, die Fehlerbehandlung der Jedis nutze und von daher in der Fehlermeldung immer angezeigt bekomme, in welcher Unit und in welcher Quelltextzeile der Fehler aufgetreten ist. Daher brauche ich (kaum) mal den Debugger, um fündig zu werden.

Abgesehen davon sind die Kombination von If-Then-Befehl nur selten kürzer als ca. 80 Zeichen und ich schrieb ja, dass ich bei "langen" If-Anweisungen ein Begin-End folgen lasse und somit der Dreizeiler der Normalfall ist.

[-=ZGD=-]

Zitat von nahpets:

Abgesehen davon sind die Kombination von If-Then-Befehl nur selten kürzer als ca. 80 Zeichen und ich schrieb ja, dass ich bei "langen" If-Anweisungen ein Begin-End folgen lasse und somit der Dreizeiler der Normalfall ist.

Case geht da nicht?

[Edit] Okay..Ich hab Zeilen gelesen..Sorry

[nahpets]

Zitat von Jumpy:

Ich habe so ein bißchen den Eindruck gewonnen, dass die Formatierung auch davon beeinflusst wird, in welchen Sprachen man noch so programmiert, sprich wie man in Java/C#/C++ die Klammern setzt, so setzt man begin/end in Delphi?

Da ist was dran, man hat mir mal (spasseshalber) vorgeworfen, ich würde in C++ Delphi-Code schreiben.

Oder sagen wir mal so: Ich schreibe Quelltext so wie ich Denke, der Quelltext bildet (meist) die Struktur meiner Gedankengänge (sofern ich denn mal welche habe ) wieder.

Wer anders an eine Problemlösung herangeht, schreibt den Quelltext auch entsprechend. Und das finde ich absolut korrekt.
Es ist nicht hilfreich, wenn ich von anderen erwarte, dass sie ihren Quelltext so schreiben, dass er meiner Denkweise entspricht. Das wird (fast) immer schiefgehen, so wie ich Quelltexte nicht in der Denkstruktur anderer schreiben kann, da scheitere ich auch immer.

Pascal/Delphi ist die Sprache, in der es mir am Einfachsten fällt, logische Gedanken "zu Papier" zu bringen. Bei C++ /Java ... hab' ich immer den Eindruck, um das zu verstehen, muss ich rückwärts denken.

Kollegen, die eher und lieber in C++, Java ... programmieren, sagten mir mal, dass es ihnen bei Pascal/Delphi genauso geht.

Für mich ist bei der Quelltextformatierung wesentlich, dass sie mit der logischen Struktur des Programmierten "zusammenpasst". Der Rest ist eher "Beiwerk". In größeren Projekten und / oder Teams, sollten sich aber alle Beteiligten an eine einheitliche Form der Quelltextformatierung (aber auch der Vergabe von Variabel-, Funktions- ... und Sonstigesnamen) halten. Dadurch erscheint mir die Verständlichkeit von Quelltexten zu steigen.

[ChrisE]

[HUMOR]
Auf die ursprünglich Frage - Die "richtige" Sourcecocde Formatierung - kann es NUR eine Antwort geben -----> 42
[/HUMOR]

Greez, Chris

[Stevie]

Wenn man sich an Clean Code hält (was primär eigentlich nix mit der Formatierung des Codes zu tun hat), ergeben sich viele hier gezeigte Fälle erst gar nicht, weil Methoden nicht über zig if Bedingungen oder Verschachtelungen verfügen (z.B. Hallo Polymorphie und Strategie Pattern).

Auch so manch "cleveres" Code Konstrukt ließe sich weitaus einfacher schreiben, wenn man z.B. das Null Objekt Pattern anwenden würde.

Was die restliche Formatierung angeht, halte ich mich weitgehend an den Borland Guide und versuche so zu formatieren, dass ich den von der IDE generierten Code nicht noch ändern muss.

[p80286]

Zitat von Neutral General:

Ein end gehört IMMER zu einem begin. Man kann es auch so sehen, dass nach einem then generell nur eine Anweisung stehen kann. Und begin/end ist eine Anweisung (die als Container für mehrere Anweisungen dient). begin-end kann auch komplett ohne if/for/while o.ä. im Code stehen. Sieht zwar seltsam aus, aber ist erlaubt und zeigt umso mehr, dass ein end immer zu einem begin gehört.

Delphi-Quellcode:

case NeutralGeneral.isright of
  true : begin end;
  false :  NeutralGeneral.isright:=true;
end;

Gruß
K-H

[-=ZGD=-]

Delphi-Quellcode:

case NeutralGeneral.isright of
  true: 
    begin 
     
    end;
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
end;

wobei jeder Case bei mir ein ELSE haben muss

Delphi-Quellcode:

case NeutralGeneral.isright of  
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
  else
    begin
    end;
end;

[Uwe Raabe]

Zitat von SProske:

Wieso sollte ich auf ein Exit keinen Haltepunkt setzen können/wollen?
Vielleicht interessiert es mich ja, ob das Exit während der Codeausführung überhaupt mal angesprungen wird (ohne bei jeder Prüfung anzuhalten).

Schon mal probiert?

[SProske]

Zitat von Uwe Raabe:

Schon mal probiert?

Klar - aber initial natürlich nur mit

Delphi-Quellcode:

if 1=1 then
  Exit;

Um jetzt festzustellen, dass es nicht mehr klappt, wenn da irgend etwas sinnvolles steht - cooles Feature ~.~