Formelsprache Programmierstil

[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);

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));

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);

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

[Thomator]

Hi Axel,

Ich denke, das ist auch vom persönlichen Geschmack und von den Programmier-Konventionen des Unternehmens abhängig.

Allerdings hält das Verwenden von tmp. Variablen ja auch nicht vom umfangreichen Kommentieren des Codes ab.

Ich stimme allerdings auch soweit zu, dass unter Notes 5, wo jeder Variable nur einmalig ein Wert zugewiesen werden kann, diese Geschichte ziemlich ausufern kann. Es wird halt irgendwann schwer, für eine Variable, die in mehreren Schritten berechnet wird, sinnvolle und aussagekräftige Namen zu finden. Das ist ja unter Notes 6 zum Glück nicht mehr der Fall.

Und grundsätzlich halte ich eben fein-granulare Formeln für übersichtlicher.
Aber wie schon gesagt: Da hat wohl jeder so seine Präferenzen...

Thomas

[Glombi]

Ich habe ab und zu mal das Vergnügen, Datenbanken für einen Kunden anzupassen, die er von einem größeren Business Partner gekauft hat- Sales bspw. Da gibt es kilometerlangen Formelsprachencode , HEUTE noch- so wie ich diesen zu Notes 3 oder 4 Zeiten auch produziert habe. Damals war das bei uns (Lotus) auch die Methodik.
Jetzt ist es einfach nur noch grauenhaft, sowas durchblicken und anpassen zu müssen. Da ist Script eindeutig besser.

Andreas

[ascom40]

Hallo.

ich stimme Andreas da völlig zu: Formeln sind ok bis zu einem gewissen Rahmen, aber irgendwann ist das nicht mehr oder nur schwer zu verstehen bzw. zu erweitern (Bernhard wird vielleicht gleich widersprechen  ).

Deshalb setze ich an umfangreichen Routinen nur noch Script ein. Da kann jederzeit ein Item dazugepackt oder eine If-Then-Else-Formel eingebaut werden und es bleibt trotzdem verständlich.

Jo

[koehlerbv]

Nein, ich widerspreche nicht: Formelsprache, wo es sein muss. Formelsprache, wo es dadurch übersichtlicher wird (das gibt es durchaus und durchaus oft). Formelsprache, wenn es die Performance erheblich befördert.

Bernhard

[ascom40]

Hallo Bernhard,

Formelsprache, wo es dadurch übersichtlicher wird (das gibt es durchaus und durchaus oft).

da hast du sicher recht, fühl dich also bitte nicht angegriffen ! Ich hatte nur bisher den Eindruck, du erwartest generell die (sicher) oft performant bessere Formelsprache.

Viele Grüße
Jo

[koehlerbv]

Ich fühle mich bestimmt nicht angegriffen. Könnte es auch sein, dass Du mich mit jemanden verwechselst ? Tode zum Beispiel ? Tode ist aber sicherlich mit kir einer Meinung, nur hat er die Benutzung der Formelsprache ein paar mal prononciert hervorgehoben. Aber durchaus in dem Sinne, wie ich es genannt habe.

Bernhard

PS: Was macht man auch mit LS in Ansichten ?  So war mein Posting auch gemeint