Lesbare Bedingungen in LotusScript

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

Ü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

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

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)

(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 ....   

[Marinero Atlántico]

Halte das auch für eine gute Idee.
Lange verschachtelte ifs sind ein Problem.

am Rande:
Ein ziemlich großer Teil der GoF Design Pattern in OO vermeiden gerade das.
Für jeden Fall gibt es eine eigene Klasse. Diese Klassen haben ein gemeinsames Interface (in Java: gemeinsame abstrakte Klasse oder Java-Interface).
Gibt es allen Klassen gemeinsame Aktionen tut man die eben in die abstrakte Klasse. 
Strategy-Pattern, Command Pattern oder Template method.
Benutzt man Reflection braucht man gar kein if-then mehr.

Könntest du hier auch mit LotusScript benutzen, wobei es da leider keine abstrakten Klassen gibt.

[koehlerbv]

Die Vereinfachung von verschachtelten Abfragen halte ich auch für ein extrem wichtiges Thema. Neben der Nachvollziehbarkeit des Codes sind dessen Wartbarkeit und Fehlersicherheit entscheidende Faktoren.

Ich setze dabei folgende Verfahren ein:
- Vereinfachung der Lesbarkeit, wie hier schön von Christian beschrieben (DANKE im Namen der Forumsnutzer !)
- Aufgliederung der Abfragen - insofern diese auf sehr wenige Zustände zurückzuführen sind, dann wird das Ergebnis immer in einer Zielvariablen geführt (ganz einfaches Beispiel: Ermittlung "muss gespeichert werden ?" Ergebnis kann nur "ja" oder "nein" sein. Nur das "jo, speichern !" wird fortgeschrieben).
- M.E. nur scheinbar üble Konstrukte wie GOTOs oder END-statements, bevor es ganz unübersichtlich wird.

Eine interessante Debatte 

Bernhard

[Semeaphoros]

Ja, Axel, Du führst noch ein wenig weiter, was ich oben schon angedacht habe. Das Fehlen von abstrakten Klassen in LS ist schade, aber nicht wirklich ein Showstopper, unbedingt nötig sind die nicht (nur ein Hilfsmittel für die eigene Ordnung )

[Marinero Atlántico]

In dem Projekt werden Design Elemente mit verschiendenen Sprachen über DXL in Datenbanken importiert/aktiviert/kontrolliert:

noch ein Dribbling an der Außenlinie:
Wir haben in einem Projekt, wo ich nicht beteiligt bin, auch so einen Fall wo ein komplexerer xml-Baum z.Zt. pro node verarbeitet wird.
Das kann sehr komplex werden, auch wenn man das relativ smart organisiert. 
Ich glaube ja persönlich, dass XMLDataBinding in vielen Fällen definitiv Sinn macht (http://www.rpbourret.com/xml/XMLDataBinding.htm).
Ist hoch auf meiner research, prey & self-exploitation agenda.   

@Jens: Vorteil von abstrakten Klassen:
- klare Kommunikation, v.a. wenn andere die Klasse nutzen (Übersicht ist wichtig). Man weiss direkt, welche Methoden gemeinsam sind und welche überschrieben_werden_müssen. Btw. werde ich langsam zum Freund des intensiven Einsatzes des Schlüsselwortes final. d.h. Methoden sind i.m.m.e.r. entweder abstract (müssen überschrieben werden) oder final (dürfen nicht überschrieben werden).

- IDEs generieren bei einer Vererbung von einer abstrakten Klasse automatisch stubs der abstrakten Methoden, so dass der Entwickler direkt weiss, welche Methoden überschrieben werden sollen.

In meiner Praxis sind abstrakte Klassen überaus wichtig.

[Semeaphoros]

Axel, völlig einverstanden, dass das praktisch ist, allerdings bringt uns die LS-IDE leider schon die Basisunterstützung nicht, also bekommen wir auch keine Stubs von abstrakten Methoden ...... ..... leider

[Marinero Atlántico]

"code against abstractions/interfaces not concrete classes" ist GESETZ Nr. 1 und GESETZ Nr. 1 ist ein bischen mehr als ein "persönliches Ordnungsprinzip.
OO sind für mich Objekte, die sich gegenseitig Nachrichten schicken.
Objekte haben eine definierte externe Schnittstelle für Nachrichten, die es verarbeiten können.
Diese Nachrichtenschnittstelle ist bei mir sehr, sehr, sehr oft als Interface (d.h. abstrakte Klasse oder java-interface) definiert. So kann die konkrete Implementierung ausgetauscht oder auch um eine zusätzliche Implementierung erweitert werden.
Natürlich kann man ein Interface auch als normale Klasse definieren.
Nur erschwert das für mich die Kommunikation über den Sinn eines Designs sehr stark.
Der Compiler forziert nicht,
- dass das Interface selbst nicht instantiiiert werden darf. 
- dass die dummy Implementierung der Interface Methoden überschrieben werden müssen (und andere Methoden allen Objekten der Klassen, die dieses Interface implementieren, gemeinsam sind).

[Semeaphoros]

Absolut richtig, nur, man strecke sich nach der Decke und arbeite mit dem, was man hat, und LS bietet da einfach nichts. OK, man kann das teilweise selber implementieren ......