Was hierbei richtig und falsch ist, muss jeder für sich selber entscheiden.
Fakt ist : Wenn Sourcecode "anders" formatiert ist - und da ist sicherlich jeder ein Gewohnheitstier - lässt er sich
1. schlechter lesen
2. langsamer lesen
Also werden Fehler übersehen oder schlechter gefunden.
Aber was ist mit den "neuen" Sprachfeatures gibt es dafür Regeln? An den Fehlern in der
IDE (Auto-End-Einfügung) oder (Doppelte generische Verschachtelung) stellt man schnell fest... Die
IDE kann damit auch nicht richtig umgehen.
Wenn man schon sehr lange programmiert ( und früher gab es noch keine Regel für Sourcecode ) hatten Proceduren gerne mal 1000 Zeilen oder mehr... Viel mehr.... Sehr viel mehr.... Was also, wenn die procedure nicht auf den Monitor passt (macht ja keiner mehr) was aber wenn? Und was ist, wenn dann um alles noch ein if muss...?
Delphi-Quellcode:
Procedure FooLang(Foo : integer);
begin
if Foo > 77 then begin
....
Gib es einen ELSE-Teil? Keinen Plan, dann scroll mal runter... Also einfach eine Regel dafür:
IF Regel:
Delphi-Quellcode:
Procedure FooLang(Foo : integer);
begin
if Foo > 77 then // if hat kein else-Teil, then hinter IF
begin
...
end;
if Foo > 77
then begin // if hat einen else-Teil und ich sehe das an der 1. Zeile...
...
end
else begin
...
end;
Was ist mit
Classen Design:
So?
Delphi-Quellcode:
type
TFoo = class
private
procedure Bla;
function Blub : Integer;
procedure Setwert(Value : Integer)
function getwert : Integer
procedure Settext(Value:String)
function gettext:String
public
Property Wert:integer read getwert write setwert;
property TestmessageValue:string read gettext write settext;
end
oder doch lieber so:
Delphi-Quellcode:
type
TFoo = class
private
Procedure Bla;
Function. Blub : Integer;
Procedure SetWert( AValue : Integer )
Function. GetWert : Integer
Procedure SetText( Const AValue : String )
Function. GetText : String;
public
Property Wert............ : Integer read GetWert write SetWert;
Property TestmessageValue : String. read GetText write SetText;
end
Die Punkte sind nur, weil das Forum die Leerzeichen löscht...
Was ist mit
anonymen Proceduren?
Delphi-Quellcode:
begin
TAynFactory.Default.RegisterObj(Function : IFoo begin result := TFoo.Create; end);
end;
Mit Sicherheit nicht... oder?
Delphi-Quellcode:
begin // #1
TAynFactory.Default.RegisterObj(
Function : IFoo
begin
result := TFoo.Create;
end);
end;
Delphi-Quellcode:
begin // #2
TAnyFactory.Default.RegisterObj(Function : IFoo
begin
result := TFoo.Create;
end);
end;
Delphi-Quellcode:
begin // #3
TAnyFactory.Default.RegisterObj( Function : IFoo
begin
result := TFoo.Create;
end );
end;
Angefangen habe ich mit Variante
#3, aber da ich mittleiweile ständig so arbeite, bin ich zu
#2 über gegangen...
Was ist mit
Fluiddesign?
Delphi-Quellcode:
begin // #1
TFMXFluidCreator<TListBoxItem>.RegisterDefault(
Procedure (LBI : TFMXFluidCreator<TListBoxItem>)
begin
LBI.Style('listboxitembottomdetail').
Height(49).
ItemMore.
OnClick(
Procedure (Sender : TObject)
var
S : String;
begin
S := TListBoxItem(Sender).
Tag.
ToString;
TEventBus.
DefaultBus.
Publish(TBusMemoMessage.Create(S));
Memo1.Lines.Add(S);
end,false);
end);
end
Delphi-Quellcode:
begin // #2
TFMXFluidCreator<TListBoxItem>.RegisterDefault(Procedure (LBI : TFMXFluidCreator<TListBoxItem>)
begin
LBI.Style('listboxitembottomdetail').Height(49).ItemMore.OnClick(Procedure (Sender : TObject)
var
S : String;
begin
S := TListBoxItem(Sender).Tag.ToString;
TEventBus.DefaultBus.Publish(TBusMemoMessage.Create(S));
Memo1.Lines.Add(S);
end,false);
end);
end
Delphi-Quellcode:
begin // #3
TFMXFluidCreator<TListBoxItem>.RegisterDefault(
Procedure(LBI: TFMXFluidCreator<TListBoxItem>)
begin
LBI.Style('listboxitembottomdetail').Height(49).ItemMore.OnClick(
Procedure(Sender: TObject)
var
S: String;
begin
S := TListBoxItem(Sender).Tag.ToString; // Das lasse ich so...
TEventBus.DefaultBus.Publish(TBusMemoMessage.Create(S));
Memo1.Lines.Add(S);
end, false);
end);
end
Delphi-Quellcode:
begin // #4
TFMXFluidCreator<TListBoxItem>.RegisterDefault( Procedure ( LBI : TFMXFluidCreator<TListBoxItem >)
begin
LBI.
{} Style( 'listboxitembottomdetail' ).
{} Height( 49 ).
{} ItemMore.
{} OnClick( Procedure ( Sender : TObject )
var
S : String;
begin
S := TListBoxItem( Sender ).Tag.ToString; // Das lasse ich so...
TEventBus.DefaultBus.Publish( TBusMemoMessage.Create( S ) );
Memo1.Lines.Add( S );
end,false );
end);
end
#1 &
#2 kann doch keiner mehr lesen... oder?
#3 ist ein Autoformat
#4 ist auch ein Autoformat die {} verhindern ein zusammen ziehen der Fluid-Elemente. Mit der Procedure im OnClick( kann man sich dann wieder streiten... Aber da ich das "procedure" immer hinten lasse - mache ich es auch so...
Case...
Delphi-Quellcode:
begin // #1
Case ch of
'A' : Blub;
end; { of case } // <- Immer, da eine der wenigen Stellen, wo es ein "end" ohne "begin" gibt.
end;
Delphi-Quellcode:
begin // #2
Case SetType
of
csCool : Blub;
csUnCool : Foo
else raise exception.Create('
SetType nicht definiert');
// IMMER, vielleicht habe ich das Set geändert und die Case vergessen?
end;
// of case
end;
Delphi-Quellcode:
begin // #3
{$REGION ' FDK CaseSelector'}
case TFDKHelper.CaseSelector<String>(AFieldName,
{0} ['Name',
{1} 'Vorname',
{2} 'Strasse',
{3} 'PLZ',
{4} 'ORT'],Function (A,B : String) : boolean
begin
Result := SameText(A,B);
end){$ENDREGION}
{Case AFieldname } of
0 : Result := 24;
1 : Result := 22;
2 : Result := 32;
3 : Result := 5;
4 : Result := 22
else raise ESystemException.Create('CaseSelector Feldname nicht in Liste: Mavarik Anrufen');
end; // of case
end;
Delphi-Quellcode:
begin // #4
//FDK CaseSelector (hier als Kommentar weil das Forum es nicht anders kann)
{Case AFieldname } of
0 : Result := 24;
1 : Result := 22;
2 : Result := 32;
3 : Result := 5;
4 : Result := 22
else raise ESystemException.Create('CaseSelector Feldname nicht in Liste: Mavarik Anrufen');
end; // of case
end;
#1 &
#2 sind meine festen Regeln...
#3 für Typen die eine Case nicht kann und das wird dann mit der Region wie
#4 dargestellt... So kann man es lesen...
Soweit mein kleine Auszug...
Mavarik
