EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen

[Rollo62]

Zitat von bernau:

Ich finde es sogar sehr schön.

Außer man ist ein Klammer-Fan so wie ich, und nutze Klammern gerne in Mathematik und Code um Teile zu separieren,
auch wenn dies nicht immer absolut notwendig ist.
Das erspart über implizierte logische Zuordnungen nachzudenken und legt die Berechnung so dar, wie es geplant ist.
Zum Verhindern von blöden Flüchtigkeitsfehler und der besseren Zuordnung logischer Zusammenhänge ist das eine gute Sache.
Hier mal ein Extrembeispiel:

Delphi-Quellcode:

if ....Assign(......FClass        )
   and ......(......FClass.CanUse ) 
   and ......(.(....FClass.ValueA 
   .............+ ( FClass.ValueB * FClass.ValueC )
               ). = 42
             ) then
  begin
  end;

vs.

Delphi-Quellcode:

if Assign(FClass) and FClass.CanUse and (FClass.ValueA+FClass.ValueB*FClass.ValueC=42) then
  begin
  end;

Wo kann man logische Fehler wohl besser erkennen?

Natürlich versuche ich das weiter zu entflechten durch negative Logik und Guards

Delphi-Quellcode:

if not Assign(     FClass        ) then
begin
    Exit;     
end;

if not FClass.CanUse then
begin
    Exit;
end;


if (.....FClass.ValueA 
     + ( FClass.ValueB * FClass.ValueC ) ) = 42 then
begin
end;

Ok, das ist sicher extremer als ich das aktuell mache, aber größtenteils Geschmackssache und Philosophie ...
Soll Jeder machen, wie er meint, was für ihn Vorteile bringt.
Für mich steht eine übersichtliche Formatierung an erster Stelle, gerade weil Logik so mehrdeutig und verheddert sein kann.

[himitsu]

Zitat von Rollo62:

Außer man ist ein Klammer-Fan so wie ich, und nutze Klammern gerne in Mathematik und Code um Teile zu separieren,

Das geht ja noch ... wir haben hier ein paar Klammer-Fetischisten, die klammern ALLES und JEDEN, sogar einzelne Variablen,
schreiben NOT wie eine Funktion (mit Klammer und ohne Leerzeichen) und nochmal 'ne Klammer drumrum und boar eh.

Code:

if    (Assign(      (FClass))) )
   and       (      (not(FClass.CanNotUse)) )
   and       ( (    (FClass.ValueA)
               + ( (FClass.ValueB) * (FClass.ValueC) )
              )   = 42
            ) then
  begin
  end;

Ach ja, AND, OR und + am Zeilenende

Code:

if (Assign(      (FClass))) ) and
          (      (not(FClass.CanNotUse)) ) and
          ( (    (FClass.ValueA) +
               ( (FClass.ValueB) * 
                 (FClass.ValueC) )
            )   = 42
         ) then

Vorne ist es immer an der selben Stelle und als Erstes (nicht sonstwo im Text hinten versteckt) ... man sieht also (nicht), dass es und wie an der vorhergehenden Zeile hängt.

[Uwe Raabe]

Um solche mehrzeiligen Conditions besser les- und wartbar zu machen, bieten sich separate function <sinnvoller Name>(...): Boolean an. Um die Performance nicht zu sehr zu beeinträchtigen, kann man die dann ja inline deklarieren.

[QuickAndDirty]

Zitat von Uwe Raabe:

Um solche mehrzeiligen Conditions besser les- und wartbar zu machen, bieten sich separate function <sinnvoller Name>(...): Boolean an. Um die Performance nicht zu sehr zu beeinträchtigen, kann man die dann ja inline deklarieren.

Compile Time Makros wären mir noch lieber.

[himitsu]

Wird von Emba abgelehnt.

Schon mehrfach danach gefragt.
Und dabei hab ich sogar eine für die Pascal-Syntax passende Variante für einfache einzeilige Makros vorgeschlagen.

Leider ist es auch nicht mehr möglich einen "Precompiler" zwischenzuschalten, so, wie es jemand bis Delphi 7 genutzt hatte.

[QuickAndDirty]

Compiletime Makros würden auch sowas bedingte generics abbilden können oder Ducktyping... Ich fände das schon ganz praktisch... besser als inlining.

[himitsu]

Ducktyping ist in Pascal schon möglich (wurde in mehreren Projekten umgesetzt, brutal mit OleVariants und Interfaces),
aber auf CodeCompletion, CodeInsight, HelpInsight und derartig nutzloes Zeugs, darf man dabei verzichten.
Auch fallen Schreibfehler erst zur Runtime auf.