Lotus Notes / Domino Sonstiges > Tipps und Tricks

Lesbare Bedingungen in LotusScript

(1/3) > >>

cgorni:
Ich weiß nicht, ob dieser Tipp hier schon irgendwo auftaucht. Es ist eine Art "Best Practice" bei der LotusScript Programmierung. Bitte entschuldigt, wenn es einen Syntax-Fehler geben sollte beim eventuellen ausprobieren. Cut&Paste programmiert es sich nicht so einfach.
Also dann:


Frage:
=====
wie schaffe ich es in LotusScript bei vielen Bedingungen in "If", "while" etc. den Überblick zu behalten?

Antwort:
======
In dem ich Boolesche Variablen (in R5 bitte Variants) benutze, um die Bedingungen sinnvoll zusammenzufassen.


Hier ein Beispiel aus einem aktuellen Projekt. In dem Projekt werden Design Elemente mit verschiendenen Sprachen über DXL in Datenbanken importiert/aktiviert/kontrolliert:

--------------------------------------------------------
dim DesignNotesTarget list as string
dim Key as string
dim TemplateNoteLanguage as string
dim TargetLanguage as string

If (Not Iselement(DesignNotesTarget(Key)) And (TemplateNoteLanguage = TargetLanguage)) or ((Iselement(DesignNotesTarget(Key)) And Not (TemplateNoteLanguage = TargetLanguage)))
...
End If
---------------------------------------------------------------


Das ist vielleicht noch beim ersten Durchlesen direkt nach der Programmierung zu verstehen, aber spätestens nach einer Woche braucht man eine Minute (oder mehr), um es nachzuvollziehen.
Deshalb sollte man die Bedingungen in sinnvolle Teile aufsplitten und in eigenen Variablen zusammenfassen:

----------------------------------------------------------------
dim hasTargetDesignNote as Boolean
dim hasSameLanguage as Boolean

hasTargetDesignNote      = Iselement(DesignNotesTarget(Key))   
hasSameLanguage          = (TemplateNoteLanguage = TargetLanguage)

If (Not hasTargetDesignNote And hasSameLanguage) or ((hasTargetDesignNote And Not hasSameLanguage)   )
...
End IF
----------------------------------------------------------------


Das Zwischenergebnis ist schon nicht schlecht, aber man erkennt immer noch nicht auf einen Blick, um was es geht. Deshalb gehen wir im Endergebnis noch einen Schritt weiter:

----------------------------------------------------------------
dim hasTargetDesignNote as Boolean
dim hasSameLanguage as Boolean
dim isDesignNoteMissing as Boolean
dim isRedundantDesignNote as Boolean

hasTargetDesignNote      = Iselement(DesignNotesTarget(Key))   
hasSameLanguage          = (TemplateNoteLanguage = TargetLanguage)
isDesignNoteMissing        = (Not hasTargetDesignNote And hasSameLanguage)   
isRedundantDesignNote   = (hasTargetDesignNote And Not hasSameLanguage)   

If isDesignNoteMissing Or isRedundantDesignNote Then
...
End If
----------------------------------------------------------------


Die Vorteile sind meiner Meinung nach
a) In der tatsächlichen If-Abfrage kann ich auch ohne (und erst recht mit) zusätzlichen Kommentar auf einen Blick sehen worum es geht.
b) Änderungen können an den Einzelteilen der Bedingung vorgenommen werden. Auf diese Weise ist der Code viel einfacher zu anzupassen und zu warten

Übrigens: in der Formelsprache kann man so etwas ähnliches machen, in dem man die obigen Variablen als Felder "Computed For Display" auf der Maske hat und in den Bedingungen in der Maske auf die Feldinhalte verweist


Grüße
C.

Semeaphoros:
Ist ein ganz guter Ansatz und bei komplexen Bedingungen sehr nützlich. Zwei Hinweise: Erstens, in R5 bitte Integer und nicht Variant (boolean ist Integer mit eingeschränktem Wertebereich, ein Subset).

Und wenn man schon so weit ist, wäre der nächste Gedanke, das ganze in ein Objekt zu packen und diese has...... Variablen als Properties zur Verfügung zu stellen, und schon wird die Uebersicht dank Kapselung gleich noch einmal erhöht.

TMC:
In der Tat eine gute Idee, die ich in LS so fast nie verwendet habe, in Formelsprache aber ständig (nicht nur bei Hide/When - Formeln).
In LS neig(t)e ich bisher immer dazu, u.a. die If-Anweisungen zu verschachteln, was aber auch nicht unbedingt immer sehr leserlich ist.

Gefährlich bei langen If - Bedingungen fand ich auch immer (trotz intensiver Verwendung von Klammern), dass man leicht den Überblick verliert, was denn nun an Gliedern, die zwischen den And/Or - Bedingungen stehen, zuerst ausgeführt wird bzw. welche Bedingung wen "sticht".

Insofern also ein sehr sinnvoller Ansatz, hier Übersicht reinzubringen.

TMC:

--- Zitat von: cgorni am 08.03.05 - 13:01:16 ---Übrigens: in der Formelsprache kann man so etwas ähnliches machen, in dem man die obigen Variablen als Felder "Computed For Display" auf der Maske hat und in den Bedingungen in der Maske auf die Feldinhalte verweist
--- Ende Zitat ---

Die Technik, mit Zwischenvariablen (Typ Boolean) zu arbeiten, geht so übertragbar auch in der Formelsprache, z.B. für HideWhen:

--- Zitat ---Zeigen wenn Autor lt. Autorenfeld oder mindestens Editor lt. ACL:
_Access := @TextToNumber(@Subset(@UserAccess(@DbName); 1));
_Zeigen1 := _Access > 3;
_Zeigen2 := @UserNamesList *= Autorenfeld1 : Autorenfeld2;
!( _Zeigen1 | _Zeigen2)
--- Ende Zitat ---

(Aus: [Formelsprache] Verbergen-Wenn (Hide-When) - Formeln)

Lässt sich natürlich auch noch beliebig erweitern.

Ich denke hier hat man fast 1:1 dieselben Möglichkeiten in LS und Formelsprache.

Semeaphoros:
Richtig, solange man keine Objekte in Formelsprache machen will ....   ;D

Navigation

[0] Themen-Index

[#] Nächste Seite