Domino 9 und frühere Versionen > Entwicklung

Formelsprache Programmierstil

(1/3) > >>

Marinero Atlántico:
Hi,

ich mache momentan ziemlich viel Formelsprache.
Dabei entwickelt sich immer mehr ein Stil, wo ich das immer mehr verschachtele.
Seh das momentan als das Beste an, es so zu machen.

zb.

--- Code: ---Rem "Neue Werte an das Feld Autor per Picklist h-i-n-z-u-fügen.";
_AutorNew := @Unique(Autor: @PickList([Custom];"":_DB;_DbView;_Title;_Prompt;4));
@setField("Autor"; _AutorNew);

--- Ende Code ---
Das folgende hingegen, ist wohl auch möglich (nicht getestet), finde es aber zu krass:

--- Code: ---@SetField("Autor"; @Unique(Autor: @PickList([Custom];"":_DB;_DbView;_Title;_Prompt;4));

--- Ende Code ---
weil man da nicht mehr debuggen kann.

Das trade-off zwischen so einem Schachtel-Stil und dem Stil mit vielen temporären Variablen, so wie:

--- Code: ---newValues := @PickList([Custom];"":_DB;_DbView;_Title;_Prompt;4);
listUnique := @Unique(newValues : Autor);
@setField("Autor"; listUnique);

--- Ende Code ---
ist wohl: debuggability vs. bessere_übersicht_weil_weniger_temporäre_Variablen.

Ich finde das letztere irgendwie unübersichtlicher. Man muss erst mal verstehen, was diese komischen Zwischenvariablen sollen. So ist aus meiner Sicht sehr viel code in Formelsprache programmiert, wobei das vermutlich wirklich drauf ankommt.

Am besten ein ordenlicher Packen an Funktionalität (wie in Bsp 1) und darüber eine Rem Zeile.

Irgendwelche Meinungen?

Gruß Axel

Glombi:
Bei mir sähe das in etwa so aus. Wichtig ist noch die Abfrage, ob Picklist was zurückgegen hat. Allerdings weiss ich gar nicht, ob der Code abbricht, wenn man in der Picklistbox auf Abbrechen klickt. Aber es geht ja mehr ums Prinzip.

newValues := @PickList([Custom];"":_DB;_DbView;_Title;_Prompt;4);
@If(newValues = "";@Return("");"");
@setField("Autor"; @Unique(newValues : Autor);


Andreas

Marinero Atlántico:
Scheint null zurückzugeben. Jedenfalls entstehen keine "Lücken" in dem Mehrfachwertefeld Autor, das ein auf sich selbst berechnetes Mehrfachwertefeld in einer Layout Regin ist .
Hingegen kann @Prompt([OKCANCELLISTMULT], etc) numerische Werte zurückliefern, wenn man nichts wählt oder abbrechen. Da muß man aufpassen.
So 100 pro sicher bin ich mir da nicht. Da gibt es noch ein Postrecalc. Aber imho ohne Auswirkungen auf dieses Feld.

Axel

Thomator:
Hi Axel,

nachdem ich in einigen Datenbanken, die ich für die Weiterentwicklung übernommen habe, Formeln von teilweise 17!!!! Zeilen Länge (mit 4 ineinander geschachtelten @If's) versucht hatte, zu lesen und zu verstehen, bin ich der festen Überzeugung, dass der einzig praktikable Weg (pers. Meinung) der über die tmp. Variablen ist. Damit meine ich, dass wirklich alles, was gekapselt werden kann, auch gekapselt wird.

Unabhängig von der Möglichkeit, den Code zu debuggen, finde ich  das Ganze einfach besser lesbar und damit verständlicher. Und gerade, wenn durch Designänderungen so eine Formel mal nicht mehr macht, was sie soll, ist das Auffinden von Fehlern so um ein Vielfaches leichter.

So riesige Formel-Konstrukte sind einfach nicht pflegbar. Da sieht man glaub ich auch nach einem halben Jahr selbst nicht mehr richtig durch.

Thomas

Marinero Atlántico:
@Thomas,

genau von der Überzeugung rücke ich ab.
Wenn ich nämlich 4 Druckseiten Formelsprachencode habe, dann werden die dauernden Temp-Variablen auch total unleserlich.
V.a. weiss man nicht, wann eine logische Einheit beendet ist.
Mit Rem Zeilen drüber, die die Intention der 4 verschachtelten ifs beschreiben, ist es tendentiell möglich, die Übersicht zu bewahren.
So ganz sicher bin ich mir aber nicht.

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite