Die "richtige" Sourcecode Formatierung?

[Uwe Raabe]

Zitat von SProske:

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

Der Compiler macht daraus einfach einen bedingten Sprung ans Ende der Methode. Es gibt also keinen Assembler-Befehl, wo dieses Exit wirklich ausgeführt wird und der Debugger davor anhalten könnte. Analog gilt das auch für Break und Continue.

[p80286]

Zitat von -=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;

Mmmm, Spaß bei Seite, das wiederum zeigt wie unterschiedlich man auch so eine simple Sache angehen kann, ohne etwas grundlegend falsch zu machen.
(könnte man uU auch bei der Formatierung so sehen; aber ein paar andere Sichtweisen können ja nicht schaden)


Gruß
K-H

[Mavarik]

Zitat von Lemmy:

um das Hirn bei der "Mustererkennung" zu entlasten

Das ist für mich der absolut wichtigste Punkt...

Eine Code-Zeile wir i.d.R.

1x geschrieben
10x gelesen

Also ist ganz klar, ich muss mich entlasten...
Das geht natürlich über die Formatierung hinaus... Dafür braucht es Regeln (Ganz alleine für mich)

Argumente haben ein A-davor...

Also

Delphi-Quellcode:

Procedure (Const AValue : String);
begin
end;

Setter haben immer eine AValue egal von welchen typen.
Array Getter und Setter haben immer INDEX <- auch in Capslock geschrieben damit es auffällt.

Type immer ein T
Interfaces immer ein I
Lokale Variablen immer ein L... (Außer unsere geliebte For-Schleifen-Variable (i) )
Früher hatten Records immer ein Typ dahinter Datum : DatumsTyp; Zeit : ZeitTyp; (Aus UCSD-Pascal Zeiten)

Bei einer Zeile

Wert := Werte;

Was ist da Werte?

Wert := Werte(); // Klar
Wert := IWerte; // Klar;
Wert := AValue; // Auch klar

Generische Parameter heißen Arg1 Arg2 Arg3
Generische Record Bestandteile heißen Item1, Item2, Item3
Generische Typen heißen <T> oder es wird die Funktionalität bezeichnet <TResult>, <TArg>, <TSource>, <TDestination>

usw...

vor und nach einem " := " kommt eine Leertaste
Das letzte end; <- hat auch ein ";" auch wenn es nicht gebraucht wird.

Von Oliver übernommen

"( Parameter : Integer )" vor und nach den () von Parametern eine Leertaste.
"{}" Als Augenpunkt: Hier geht es weiter und damit der Autoformatter die Zeile nicht ändert.


Dann noch die praktischen Sachen..

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
  ,Unit2
  ;

Einfacher um mal eben eine Unit mit // aus zu schalten...

Ich könnte noch ewig so weiter machen - stelle ich gerade fest...

Mavarik

[-=ZGD=-]

Zitat von p80286:

Zitat von -=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;

Mmmm, Spaß bei Seite, das wiederum zeigt wie unterschiedlich man auch so eine simple Sache angehen kann, ohne etwas grundlegend falsch zu machen.
(könnte man uU auch bei der Formatierung so sehen; aber ein paar andere Sichtweisen können ja nicht schaden)


Gruß
K-H

Definitiv gibt es zig verschiedene Arten.
Das mit dem ELSE war kein Spaß.

[p80286]

Spaß bezog sich auch eher auf NeutralGeneral.IsRight


Gruß
K-H

[Lemmy]

Zitat von -=ZGD=-:

[DELPHI]
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;

ähm... du meinst hoffentlich eher:

Delphi-Quellcode:

case NeutralGeneral.isright of  
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
  true: 
    begin
    end
  else
    begin
      raise Exception.Create();
    end;
end;

so schnell wird Spaß zum Ernst des Lebens

Zitat von Mavarik:

Zitat von Lemmy:

um das Hirn bei der "Mustererkennung" zu entlasten

Das ist für mich der absolut wichtigste Punkt...

Eine Code-Zeile wir i.d.R.

1x geschrieben
10x gelesen

eben, und mind. 5x von anderen. Sprich: Ich schreibe / formatiere Code weniger für mich und schon gar nicht für den Compiler, sondern für andere. Und je besser die mit meiner Lösung klar kommen, desto eher besteht die Chance, dass Fehler gefunden werden bzw. sie meinen Code weiter nutzen und damit steigt die Chance dass am Ende Geld gespart wird....

[Stevie]

Zitat von Mavarik:

Bei einer Zeile

Wert := Werte;

Was ist da Werte?

Wert := Werte(); // Klar
Wert := IWerte; // Klar;
Wert := AValue; // Auch klar

Bei dieser Argumentation, die ich schon oft gesehen habe, frage ich mich immer:
Welche Information bringt es mir, zu sehen, von welcher Art der rechte Ausdruck ist - imo ist diese Information unnötig und in der Regel nicht notwendig.
Da man normalerweise seine Elemente vernünftig benennt (und ich meine nicht mit nem Prefix, obs ein Parameter, lokale Variable oder sonst was ist, sondern das, was dieses Element an Daten enthält), ergibt sich die Frage, ob ich eine Funktion aufrufe oder aus einer lokalen Variable oder einem Parameter den Wert hole, beim Lesen nicht.

Zitat von Mavarik:

Dann noch die praktischen Sachen..

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
  ,Unit2
  ;

Einfacher um mal eben eine Unit mit // aus zu schalten...

Bei dieser Formatierung frage ich mich immer, was daran nun einfacher auszuschalten ist, als bei:

Delphi-Quellcode:

uses
  System.SysUtils,
  Unit1,
  Unit2;

Bei deiner kannst du SysUtils nicht einfach rausnehmen, da dann das Komma vor Unit1 stört, bei meiner nicht Unit2, da dann das Semikolon fehlt. In beiden Fällen gibt es eine Zeile, die nicht funktioniert. Und in beiden Fällen kann man die Units ein einer solchen Reihenfolge schreiben, dass die problematische Zeile eine ist, die man in den meisten Fällen nicht auskommentieren möchte (ok, wenn nun in Unit1 oder Unit2 Symbole aus SysUtils verdeckt werden, dann hat man bei einer Umordnung natürlich gelitten, aber wer macht sowas schon ).

[Mavarik]

Zitat von Stevie:

Bei dieser Argumentation, die ich schon oft gesehen habe, frage ich mich immer:
Welche Information bringt es mir, zu sehen, von welcher Art der rechte Ausdruck ist - imo ist diese Information unnötig und in der Regel nicht notwendig.

Ganz einfach...

1. Ich weiß sofort worum es geht ohne zu scrollen...
2. Wenn ich einen Funktionsaufruf sehe... Ist es eben keine einfache Zuweisung... Bedeutet bei einem Refactoring nach:

Delphi-Quellcode:

begin
  TTask.Run(Procedure
    begin
      Wert := Werte(); // Zugriff auf VCL???
    end;
end;

Muss ich nachsehen, ob darin nicht etwas steht wie:

Delphi-Quellcode:

Function Werte : Integer;
begin
  Caption := 'Wert geholt';
  Result := 42;
end;

Zitat von Stevie:

Bei deiner kannst du SysUtils nicht einfach rausnehmen, da dann das Komma vor Unit1 stört, bei meiner nicht Unit2, da dann das Semikolon fehlt. In beiden Fällen gibt es eine Zeile, die nicht funktioniert. Und in beiden Fällen kann man die Units ein einer solchen Reihenfolge schreiben, dass die problematische Zeile eine ist, die man in den meisten Fällen nicht auskommentieren möchte

Na warum soll ich auch Sysutils raus nehmen... Das steht doch mit Sicherheit da, weil es gebraucht wird..
Wenn ich also eine Liste habe kann ich einfach "meine" Units raus nehmen...

Delphi-Quellcode:

Uses
  System.SysUtils
//  ,Unit1
  ,Unit2
  ;

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
//  ,Unit2
  ;

Delphi-Quellcode:

Uses
  System.SysUtils
//  ,Unit1
//  ,Unit2
  ;

Klasse oder?

Mavarik

[Stevie]

Zitat von Mavarik:

1. Ich weiß sofort worum es geht ohne zu scrollen...
2. Wenn ich einen Funktionsaufruf sehe... Ist es eben keine einfache Zuweisung... Bedeutet bei einem Refactoring nach:

Nonsense Code gewinnt imo keinen Punkt bei dieser Argumentation, weil:
1. unpassender Name, der nämlich genau dazu führt, dass ich nachschauen muss, was sie macht -> sowieso schlecht
2. Funktion macht mehr als eine Sache (was wiederum dazu verleitet ihr einen prägnanten/unaussagekräftigen Namen zu geben)

Zitat von Mavarik:

Klasse oder?

Wie erwähnt, dann stell ich bei mir eine Unit nach unten, die ich aller Wahrscheinlichkeit nach nicht herausnehme, und habe dasselbe erreicht.

[p80286]

Das mit den Units, mache ich genauso wie Mavarik, wobei man bei der ersten Unit natürlich gekniffen ist.
Man kann halt nicht alles haben.

Zitat von Stevie:

1. unpassender Name, der nämlich genau dazu führt, dass ich nachschauen muss, was sie macht -> sowieso schlecht

Dann gehörst du aber zu sehr glücklichen Menschen, die gleich bei der ersten Eingabe direkt wissen, was der treffende Name ist. Ich brache immer 2 ode drei Überarbeitungen, bis alles so ist, daß ich auch in einem Jahr noch verstehe wie der Code funktioniert.

Gruß
K-H