Einrücken ::: ::: Wie rückt ihr ein?

[Micha88]

Ich persönlich rücke in "Einser-Schritten" ein.

Also sehr gerne so:

Delphi-Quellcode:

procedure Button1.Click(Sender: TOBject);
begin
-if 1 > 0 then // Leerzeichen rechts und links von >
--begin
---// Do something
--end;
-Label1.Caption := 'Mich gibbet net!' // Label auf selbe Höhe wie "if"
end;

Die schlimmste Formatierung die ich je gesehen habe sah in etwa so aus:

Delphi-Quellcode:

procedure Button1.Click(Sender: TOBject);
--begin
-----if 1 > 0 then // Leerzeichen rechts und links von 
-----begin
-----// Do something
-----end;
-----Label1.Caption := 'Mich gibbet net!' // Label auf selbe Höhe wie "if"
--end;

[Phantom1]

so mach ichs eigentlich immer:

Delphi-Quellcode:

procedure Button1.Click(Sender: TOBject);
var
  c: Integer; 
begin
  if 1 > 0 then begin
    Label1.Caption := 'test1';
  end else begin
    if x = y then begin
      for c := d to e do begin
        // Do Something
      end;
    end;
    Label1.Caption := 'test2';
  end;
end;

damit wäre ich aber auch noch einverstanden:

Delphi-Quellcode:

procedure Button1.Click(Sender: TOBject);
var
  c: Integer; 
begin
  if 1 > 0 then
  begin
    Label1.Caption := 'test1';
  end 
  else
  begin
    if x = y then
    begin
      for c := d to e do
      begin
        // Do Something
      end;
    end;
    Label1.Caption := 'test2';
  end;
end;

und alles andere geht bei mir garnicht! ^^

@MichaelLinden: da du nach der If-bedingung das begin um eins eingerückt hast musst duch auch das begin im procedurenkopf um eins einrücken, wenn schon denn schon ^^

[mr_emre_d]

So mache ich es immer und hatte nie Probleme damit, mich in Codes, die ich länger nicht mehr angerührt hatte, wieder einzufinden :)

Code:

// LF = Zeilenvorschub
// -  = Leerzeichen -- da bestimmte Stellen im Code Abschnitt nicht richtig formatiert werden !
TData = Record
--X, Y,
--Z, A: Single;
--Wow, Woooow,
--WowWowWoW: String;
end;

procedure-Name(); // "()" auch wenn keine var übergeben werden !
var  // + LF
--X, Y,  // max 2 vars in einer Zeile !
--i, j: Integer;
--aha: TData;
begin
--doBlub1();  // Methodenaufruf
--if True then
--begin
----doBlub2();  // auf wenn nur 1 Zeile Code ausgeführt werden muss: begin und end dürfen nicht fehlen !
--end else      // entspricht nicht der Styleguide ! aber somit spart man sich eine Zeile und sieht auch besser aus :P
--begin
----doBlub3();
----doBlub4();
--end;
--X := -10;
--Y := ABS( X );  // --> proc/func(-Value-);
--aha.Z := 0;
--for i := Round( X ) to Round( Y ) do  
--begin
----with aha do
----begin
------Z := Z + i;
----end;
--end;
--// AUSNAHMEN:
--for i := Round( X ) to Round( Y ) do // wenn in der Schleife mit irgendwelchen datenstrukturen gearbeitet wird, dann...
--with Aha do
--begin
--  Z := Z + i;
--end; 
--with Aha do
--begin  // das gilt auch für Var/Struktur-Deklarationen
----X         := 10;
----Y         := Random();  // auch wenn functionen keine variablen verlangen: "()" dürfen nicht fehlen !
----Wow       := X;
----Woooow    := Wow;
----WowWowWoW := Woooow; 
--end;
end;

MfG :D

[littleDave]

Hier mal meine Variante

Delphi-Quellcode:

type
  TData = record
    x, y, z, a : single;
    Wow        : string;
  end;

procedure BlubName(aTest: string; aTest2: integer);
var i       : integer;
    value   : string;
    pObj    : TObject;
    bmp     : TBitmap;
begin
  // ein Kommentar
  if TestMethode(aTest) then
  begin
    // eine Case-Abfrage
    case aTest2 of
    1    : begin

           end;
    1024 : aTest := 'abc';
    else   aTest := 'n Fehler';
    end;
  end else
  begin
    { Längere Beschreibung
      die auch mal über mehere Zeilen geht }
    BlubName(aTest + IntToStr(aTest2), aTest2 + 1);
  end;

  (* Quelltext der auskommentiert wurde + Grund

     if i = 0 then
        i := 5
     else 
        i := 5 + i;
  *)


  { ein Try-Finally-Konstrukt schreib ich erstmal automtisch hin
    sobald ich ein Create aufrufe }
  pObj := TObject.Create;
  try
    value := pObj.ClassName + ' - ' + pObjc.Irgendwas;
 
    for i:=0 to pObj.Count-1 do
      if pObj.Available[i] then
         pObj.Add(value)
      else
         pObj.Available[i] := False; 

    bmp := TBitmap.Create;  
    try 
      // die Strings sind bei mir fast immer Konstanten oder variablen
      if not FileExists('hm, keine Ahnung') then
         raise Exception.Create('Konnte ''hm, keine Ahnung'' nicht finden');

      bmp.LoadFromFile('hm, keine Ahnung');
      if FileExists('woanders hin') then
         DeleteFile('woanders hin');

      bmp.SaveToFile('woanders hin');
    finally
      bmp.Free;
    end;
  finally
    { FreeAndNil benutz ich nur bei Objekten, die in einer Klasse oder
      Global gespeichert sind }
    pObj.free;
  end;
end;

MfG :D[/quote]

[Micha88]

Dass man nach einem If das end und else jeweils in eine Zeile packen soll, finde ich aber auch nicht so gut.

ich mache es auch eher so:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
-if a = b then
--begin
---// etwas machen
--end else
---begin
----// etwas machen
---end;
end;

[alzaimar]

Um es kurz zu machen: Ich verwende eine Code-Formatter und passe die Optionen so an, das nicht so viele Zeilen verbraten werden. Früher habe ich extremen Wert auf Formatierung gelegt, und Alles, aber auch wirklich Alles irgendwie untereinander geschrieben, also z.B. auch die ':' in Var-Deklarationen. Irgendwann war mir das aber zu mühselig und als ich das erste mal einen Formatter ausprobiert habe, hab ich mich damit abgefunden, das die automatische Formatierung etwas suboptimal ist. Aber dafür habe ich nun auch wieder Zeit für andere Dinge im Leben :mrgreen:

[DeddyH]

Mir ist das mittlerweile sch***egal, wie andere einrücken, solange sie dies sinnvoll und nachvollziehbar tun, so dass der Code lesbar ist.

[alzaimar]

Zitat:

Zitat von DeddyH

Mir ist das mittlerweile sch***egal, wie andere einrücken, solange sie dies sinnvoll und nachvollziehbar tun, so dass der Code lesbar ist.

DeddyH: Das ist fast die Quintessenz dessen, was man über Codeformatierung sagen kann. Eines fehlt noch: Im Team einigt man sich auf eine Variante. Und natürlich ist der mit einem einfach aufzurufenden automatischen Codeformatter zu erledigen (DelFor, JCF etc.).

[oldmax]

Hi
Auch wenns mittlerweile vielleicht schon langweilig wird, läßt man die vielen Links mal weg und antwortet auf die Frage direkt. wär's vielleicht mit 10 Antworten getan.
( Viel mehr Variationen beim Einrücken kann ich mir eigentlich nicht vorstellen ... )
Wenn mich einer fragt, wie rückst du ein ist beine Antwort:

Delphi-Quellcode:

Procedure ....
Begin
  If  ... then 
  begin
    While .... do
    begin
      //einrücken, das ist die Anweisungsliste der While - Schleife etc.
    end;
    //Auch das hier ist eingerückt, weilszum If gehört....
  end;
  If  ... then 
  Begin
    ...// zur Abwechslung mal else
  end else
  Begin
    ... //so steht begin immer am Anfang des Bereiches
    ... //  und in der Spalte des zugehörigen End
  end;
  //und das zur Procedure....
end;

Ich kann nicht verstehen, warum manche nicht darauf achten. Vernünftig einrücken erhöht die Lesbarkeit und hilft immens bei der Fehlersuche, speziell bei fehlenden End-Anweisungen.
Auch lassen sich Bereiche besser untersuchen.
Ob nun 2, drei oder 4 Leerzeichen oder Tabs oder sonstwas zum Einrücken benutzt wird, halte ich eigentlich nicht für so wichtig. Der Code muß lesbar sein, sauber getrennt. Darauf kommt es an. Häufig ist der Ausweg von großen Begin ... End -Bereichen die Möglichkeit, Proceduren oder Functions aufzurufen. So kann z.B. eine Anweisung
If (Bedingung) then TuDies
else TuDas
So, jetzt hab ich hoffentlich auf die Frage eine Antwort gegeben.
Gruß oldmax

[Angel4585]

Meine Einrückung:

Delphi-Quellcode:

procedure TForm1.Test;
begin
for i:= 0 to 4 do
  begin
  if i < 3 then
    begin
    MachWas;
    MachNochWas;
    end
  else
    begin
    MachWasAnderes;
    end;  
  end;
end;

Ich finde so kann man das am Besten lesen, aber da hat wohl jeder seinen eigenen Stil

[MaBuSE]

Hallo zusammen,
ich finde es immer wieder lustig, wenn man eine Benachitigung zu einem Thema bekommt,
in dem man vor über 2 Jahren etwas geschrieben hat und sich gleich alle drauf stürzen und posten. ;-)
Das ist keine negative Kritik - ich finde das gut.
Es zeigt, das die "alten" Beiträge gelesen werden und auch noch heute interesannt sind.

Ich möchte zu dem Thema auf meinen Beitrag von 2006 verweisen, da er immer noch meiner Meinung entspricht:
http://www.delphipraxis.net/internal...=640007#640007

Es ist egal wie man im Editor formatiert, wenn man die Formatierung vor/nach dem abspeichern mit einem CodeFormater bearbeitet. Damit ist gewärleistet, dass der Code immer gleich formatiert ist.
Die CodeFormater kann man ja nach eigenen Wünschen konfigurieren.

Zitat:

Zitat von MichaelLinden

Die schlimmste Formatierung die ich je gesehen habe sah in etwa so aus:

Delphi-Quellcode:

procedure Button1.Click(Sender: TOBject);
--begin
-----if 1 > 0 then // Leerzeichen rechts und links von 
-----begin
-----// Do something
-----end;
-----Label1.Caption := 'Mich gibbet net!' // Label auf selbe Höhe wie "if"
--end;

Das ist doch super formatiert.

So was wie ich damals (siehe Link oben) im Beispiel postete, hatt eine Firma, für die ich früher mal arbeitete auch schon mal an einen "guten" Kunden ausgeliefert. Ich musste damals extra einen Obfuicator schreiben, der alle Variablen, Konstanten und Objekte in a1, a2, a3, ... umbenennt. Die Funktionen und Procedure wurden auch in a5, a6, a7, ... umbenannt und alle Kommentare entfernt. Alle Stringkonstanten wurden in einen const Block geschoben und die Konstanten wurden auch a8, a9, a10, ... benannt.

Delphi-Quellcode:

function Foo(a, b, c, d:Integer):Integer; var x, y:Integer; begin If a>b then 
{1. If groß} if a * b > c+d then begin {Verschachtelte ifs klein} For x:=0 to 
Width-1 do {Das gleiche mit For} for y:=0 to Height-1 do begin Inc(a, 1); Dec
(b, 1); end; end; end;

Dein Code würde dann etwa so aussehen:

Delphi-Quellcode:

...
const a4=1;a5=0;a7='Mich gibbet net!'
...
procedure a1.a2(a3: TOBject);begin if a4>a5 then begin end; a6.Caption:=a7 end;
...

Ist doch auch viel kürzer ;-)

Heute würde ich die Namen allerdings _1, _2, _3, ... wählen, ich wusste damals noch nicht das das auch geht :mrgreen:
Oder um den Code noch unleserlicher zu machen einfach Schlüsselwörter verwenden und eine Nummer anhängen.

Delphi-Quellcode:

...
const begin4=1;end5=0;if7='Mich gibbet net!'
...
procedure for1.do2(function3: TOBject);begin if begin4>end5 then begin end; exit6.Caption:=if7 end;
...

Mit Kommentaren kann man den Leser noch weiter verwirren. Es eignen sich z.B. nonsens Programmcode oder auch die Lizenzbedingungen. Auf das Liebelingsgedicht würde ich verzichten um nicht gegen das Urheberrecht zu verstoßen.

Delphi-Quellcode:

...
const{a1=2,a2='nonsens'}a4=1;a5=0;a7='Mich gibbet net!'
...
procedure{ein}a1.a2{paar}(a3:{Kommentare}TOBject);begin(*statt*)if//der
a4>a5{Leerzeichen}then{kommen}begin{auch}end;{gut}a6.Caption:=a7{.}end;
...

Viele Grüße
MaBuSE

[richard_boderich]

@Mabuse

Warum sollte man den Code unleserlicher machen wollen? Wer den Code nicht haben soll, kriegt ihn nicht. Und Assemblerfreaks
lassen sich davon eh nicht beeindrucken. Es sei denn du redest von Delphi.Net?

[alzaimar]

Du weisst, dass das -zumindest bei einem Werksvertrag- unzulässig ist. Ich würde mir das auch nicht mit Stolz auf die Brust schreiben, was ich für ein toller Kundenverarscher bin.

Du weisst auch, das Du/deine Firma im schlimmsten Fall haftbar gemacht werden kann: Wenn ihr in irgendeiner Weise gegen den Werksvertrag verstößt (z.B. zu hohe Stundensätze verlangt oder allgemein das Abhängigkeitsverhältnis ausnutzt) oder einfach nicht mehr zur Verfügung steht, und Euer Kunde dann zwangsweise eine andere Firma mit der Softwarepflege beauftragen muss, dann dürft Ihr die Extraarbeit bezahlen und im schlimmsten Fall etwaige Schäden des Kunden, die durch die Verzögerung angefallen sind, gleich mit. Ich hätte die Software in dieser Form erst gar nicht abgenommen.

Falls Ihr Euren Kunden bezüglich der Überlassung von Quelltext nicht vertraut, dann gibt andere Möglichkeiten, z.B. Notare oder Online-Dienste, die als Mittelsmann und Quelltexttresor dienen.

Zitat:

Zitat von richard_boderich

Wer den Code nicht haben soll, kriegt ihn nicht.

Ganz so einfach ist es nicht. Ein Werksvertrag bedingt in jedem Falle die Überlassung des Quelltextes. Man muss im Vertrag die Überlassung explizit ausschließen.

[MaBuSE]

Zitat:

Zitat von richard_boderich

@Mabuse: Warum sollte man den Code unleserlicher machen wollen? Wer den Code nicht haben soll, kriegt ihn nicht.

Ganz so einfach ist es nicht.
Eine Firma, für die ich früher mal gearbeitet habe, hatt damals für einen Kunden einen Auftrag programmiert. Obwohl der Kunde nichts bezahlt hat (nicht bezahlen konnte), hat er die Firma via Vertragsbedingungen gezwungen, den Quelltext rauszugeben.
(Der Kunde wusste vor dem Auftrag, dass er nicht zahlen kann.)
Der Quelltext musste nachweislich kompilierbar sein.
Wir haben viel Arbeit in das Projekt gesteckt und waren ziemlich sauer keine Geld dafür zu bekommen.
Aus diesem Grund haben wir den Quellcode quasi unbrauchbar gemacht.
Den Quellcode wieder herzustellen sollte den Kunden so viel Zeit kosten, dass es sich nicht lohnt.

Das war der Rat von unserem Anwalt, da davon auszugehen war, dass der Kunde den Quelltext weiterverkaufen wollte.

Das war völlig legal, und auch in diesem speziellem Fall sinnvoll.
(Es war auch nicht meine Entscheidung, ich war nur der Programmierer, der den Quellcode verunstalten musste.)

Natürlich hat die Firma das sonst noch nie gemacht und gab in der Regel immer vorbildlich formatierten und vor allem gut dokumentierten Quellcode an den Kunden weiter. Eine Kundenbeziehung lebt immer vom geben und nehmen. Man ist ja schließlich an langfristigen Kundenbeziehungen interessiert.

Nachtrag:

Zitat:

Zitat von alzaimar

Du weisst, dass das -zumindest bei einem Werksvertrag- unzulässig ist. Ich würde mir das auch nicht mit Stolz auf die Brust schreiben, was ich für ein toller Kundenverarscher bin.

Ich kann Dich beruhigen, das geschah alles in Absprache mit einem Anwalt, der sich auf Softwarerecht spezialisiert hatte.
Ich bin nicht Stolz einen Kunden verarscht zu haben, aber ich bin auch nicht Stolz von diesem Kunden verarscht worden zu sein.

[->Ende der Diskussion, da OT]
Wenn jemand was Näheres wissen will, kann er mich gerne per PN anschreiben!!!

[MaBuSE]

[equote="MaBuSE schrieb in http://www.delphipraxis.net/internal...=613634#613634 "]...Hier eine Liste von verschiedenen Coding Standards:

• Borland empfiehlt folgende Formatierungsregeln:
  http://community.borland.com/article...,10280,00.html
  ...
• Deutsche Übersetzung der Borland Style Guides
  http://www.dsdt.info/grundlagen/styleguide/
  ...
  
• Delphi coding Standards
  Maintained by Mustafa GÖKMEN
  http://gokmen.selcuk.edu.tr/document.../delphi/cs.php
  ...

[/equote]

• Die Links funktionieren zwar noch, haben sich aber geändert (Weiterleitung)
  alt: http://community.borland.com/article...,10280,00.html
  neu: http://dn.codegear.com/article/10280
  
  alt: http://www.dsdt.info/grundlagen/styleguide/
  neu: http://www.delphi-treff.de/delphi-styleguide/
  
• Folgende Links funktionieren icht mehr:
  http://gokmen.selcuk.edu.tr/document.../delphi/cs.php

[p80286]

Hallo zusammen,

nachdem ich mich durch die meisten Beiträge gewühlt habe eine Frage:
warum bekommt bei den meisten von euch das begin eine neue Zeile?

Delphi-Quellcode:

if formatrichtig then
begin
  machdas(erste);
  machdaszweite;
end
else
begin
  machwasanderes;
  machsrichtig;
end;

mir gefällt folgende Variante besser:

Delphi-Quellcode:

if formatrichtig then begin
  machdas(erste);
  machdaszweite;
end
else begin
  machwasanderes;
  machsrichtig;
end;

vor allem ohne Syntaxhighlighting!

Vor vielen Jahren gab es mal Zeitschriften, deren Ehrgeiz darin bestand, Sourcen mit möglichst wenig Zeilen zu drucken.
Diese Art von Formatierung wurde genauso vehement verteidigt wie es hier einige mit Ihrer Lieblingsformatierung tun.
Ausserdem gab es mal Compiler, die Blockbildung durch Einrückung (2 oder 4 Blanks, keine Tabs) steuerten!
So etwas kann Vorlieben auch prägen.

Gruß
K-H

[Phoenix]

Zitat:

Zitat von p80286

warum bekommt bei den meisten von euch das begin eine neue Zeile?

Das hat einen ganz einfachen praktischen grund: Man erkennt sofort auf einen Blick, ob es wirklich ein Codeblock, oder nur eine einzelne Zeile ist.

Beispiel:

Delphi-Quellcode:

if (DasHierIstEinLangerBoolscherAusdruckMitEinemSprechendenNamen and NochEinLangerAusdruck) then
  DoSomething();
DoWasAnderes();

Delphi-Quellcode:

if (DasHierIstEinLangerBoolscherAusdruckMitEinemSprechendenNamen and NochEinLangerAusdruck) then begin
  DoSomething();
DoWasAnderes();

// einize andere Zeilen
end;

Wenn Du, wie im zweiten Beispiel, das Begin hinten hast und nicht auf einer neuen zeile, und dann darunter
noch einen Einrückungsfehler wie bei DoWasAnderes(), dann kann man sich ungeheuer schnell verlesen. Ein

Delphi-Quellcode:

if (DasHierIstEinLangerBoolscherAusdruckMitEinemSprechendenNamen and NochEinLangerAusdruck) then
begin
  DoSomething();
DoWasAnderes();

  // einize andere Zeilen
end;

Ist um längen klarer und zeigt auch gleich, dass man einen Einrückungsfehler hat.

[alzaimar]

Zitat:

Zitat von p80286

warum bekommt bei den meisten von euch das begin eine neue Zeile?

Weil CodeGear das so vorgibt.

[DeddyH]

Und man das schon zu TurboPascal-Zeiten so gemacht hat.

[MaBuSE]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von p80286

warum bekommt bei den meisten von euch das begin eine neue Zeile?

Weil CodeGear das so vorgibt.

gute Antwort ;-) ( -> http://dn.codegear.com/article/10280#4.3 )

Ich halte mich auch an die Empfehlung von Borland.

Man kann in jedem beliebeigen Editor (wenn die Einrückung durchgehend ist) vor das e von end gehen und mit der "Nach Oben"-Taste das zugehörige begin suchen (und auch finden).
Das geht eigentlich immer außer bei try und case aus diesem Grund schreibe ich meist auch

Delphi-Quellcode:

...
  try
    case x of
      1: Eins;
      2: Zwei;
      3: Drei;
    else
      Rest;
    end; //of case
  except
    on E: Exception do 
    begin
      ...
    end; 
  end; // of try..except
...

[tomsson74]

Mit dieser "korrekten" Variante kann ich mich beim besten Willen nicht anfreunden.

Delphi-Quellcode:

  // CORRECT
  if A < B then 
  begin
    DoSomething; 
    DoSomethingElse;
  end 
  else 
  begin
    DoThis;
    DoThat;
  end

Ich bevorzuge eher das hier:

Delphi-Quellcode:

  // INCORRECT
  if A < B then begin
    DoSomething; 
    DoSomethingElse;
  end else begin
    DoThis;
    DoThat;
  end;

Tja, habe mich soeben als "Falsch-Programmierer" geoutet :D

[stahli]

Ich kann mich den Vorrednern anschließen.
Früher habe ich das "begin" z.B. auch immer in der gleichen Zeile geschrieben und mir das inzwischen aber abgewöhnt. Es ist viel übersichtlicher, das begin in die nächste Zeile zu schreiben.
Wenn ich jetzt alte Quelltexte von mir lese ... :duck:

Außerdem schreibe ich jetzt auch Anweisungen nach if .. then in die nächste Zeile um 2 Zeichen eingerückt.

Logische Bedingungen hatte ich IMMER in Klammern gesetzt (sogar boolsche Variablen) und fand das damals sinnvoll

Delphi-Quellcode:

if (Flag) then TuWas;

Das ist aber eigentlich eher verwirrend - finde ich heute.

Delphi-Quellcode:

if Flag then
  TuWas;

... ist ja völlig i.O.


@tomsson74
Du hast Recht, Deine Variante sieht hübscher aus. Aus Gründen der Einheitlichkeit mache ich es aber trotzdem immer "richtig" :wink:

stahli

[MaBuSE]

Zitat:

Zitat von tomsson74

Tja, habe mich soeben als "Falsch-Programmierer" geoutet :D

Nein,
es gibt hier kein richtig oder falsch.
Es sollte nur darauf geachtet werden, dass es durchgehend nach einer Richtlinie gemacht wird.
Wenn es einem nicht gefällt, kann er es ja mit einem CodeFormater "richtig" stellen.

Mal Tab zum Einrücken, mal Leerzeichen, mal eins oder zwei oder drei, mal gar nicht eingerückt,
mal mehrer Befehle in einer Zeile, mal ...
Das ist es was den Code unübersichtlich macht.

[alzaimar]

Zitat:

Zitat von DeddyH

Und man das schon zu TurboPascal-Zeiten so gemacht hat.

Ich nich.

[p80286]

wow was für eine Reaktion,

das riecht beinahe nach Glaubenskrieg!
Aber es gab auch ein paar - wie ich finde- gute Argumente.
Wenn ich mir die Vorgaben von Borland/CodeGear so anschaue

Delphi-Quellcode:

// correct

wäre gut durch

Delphi-Quellcode:

// recommended

zu ersetzen.
Und nichts für ungut, nur weil irgendjemand etwas sagt/behauptet muß ich das ja nun nicht glauben. Eine Begründung für ein vernünftiges Verhalten sollte doch nicht zuviel verlangt sein.

Gruß
K-H