Domino 9 und frühere Versionen > Entwicklung

Nochmal Function: 2 Rückgaben (z.B. Array + Integer)

<< < (3/3)

Hernan Cortez:
Muss aber jetzt noch erwähnen, dass diese Praxis zu wirklichen Problemen führen kann, wenn jemand das Programm ändern will.
In 2 Wochen ändert jemand da einfach mal den Variablennamen und bricht somit das allgemeine Design der Funktion. Das pass_by_reference läuft dann nicht mehr.
Von solchen Praktiken wird eigentlich abgeraten und du solltest es zumindestens sehr, sehr gut im code dokumentieren.

Gruß Axel
 

koehlerbv:
Axel, ich stimme Dir vollkommen zu. Aus langer Erfahrung ...
Mit Bezug auf Matthias' Problem folgendes:
Eine Function sollte immer einen eindeutigen Wert zurückgeben, über den die erfolgreiche Abarbeitung der Function durch das aufrufende Programm kontrolliert werden kann. Das sollte *niemals* ein referenzierter Parameter sein. Solch einer sollte nur ergänzend zu Rate gezogen, wenn ein Fehler erkannt wurde.
Welche Parameter per reference übergegen werden (was sie ja per default sind - auch das sollte man nie vergessen !), sollte dick und fett in den Routinen dokumentiert werden.

Wegen dem Default "Parameter werden per Reference übergeben" (was durchaus eigentlich sehr unsauber ist):
Wer sowas baut
Function ArraySort (vOrigArray as Variant) as Variant
darf eben nicht erarten, dass die Variable, die an vOrigArray übergeben wurde, danach noch unsortiert ist. Um sowas sauber zu handeln, müsste die function wie folgt deklariert werden:
Function ArraySort (ByVal vOrigArray as Variant) as Variant
Das kann durchaus entscheidend sein !

Meine Erfahrung:
Functions sollten eindeutig einen Erfolgs- oder Misserfolgsstatus zurückliefern.
Also entweder:
Function GetSetupDocument () As NotesDocument
- Rückgabe is  Nothing - die Sache ging in die Hose ! Das aufrufende Modul muss reagieren
oder
Function GetSetupDcoument (docSetup As NotesDocument) as Integer
- wenn diese Function False zurückgibt, war was oberfaul, andernfalls findet sich in der an docSetup übergebenen Variablen jetzt das gewünschte NotesDocument.

Das Ganze kann man natürlich um Fehlercodes / -meldungen und vieles andere ergänzen:
Function GetSetupDocument (docSetup As NotesDocument, szErrorMessage As String) as Integer
- Wenn der Rückgabewert jetzt False ist, sollte die Function in szErrorMessage gespeichert haben, was der Grund für das Scheitern war.

Das Ganze lässt sich jetzt beliebig ausbauen - nur einen eindeutigen, klaren, nachvollziehbaren roten Faden muss das Ganze haben.

HTH,
Bernhard

animate:

--- Zitat von: El Indio Mapuche am 29.05.04 - 23:19:32 ---Leicht verdribbelt, Herr Kollege.  ;D
Variablen werden in LotusScript standardmässig by reference übergeben:

--- Ende Zitat ---

naja, ob das jetzt standardmäßig ist, oder nicht ist ja egal. Hauptsache by reference, oder?

Hernan Cortez:

--- Zitat von: Thomas Völk am 30.05.04 - 11:15:24 ---
naja, ob das jetzt standardmäßig ist, oder nicht ist ja egal. Hauptsache by reference, oder?

--- Ende Zitat ---
Sorry: War nicht so gemeint. Ich hab das dann selbst nochmal ausprobiert und mir war gar nicht mehr präsent, dass die Variablen defaultmässig by reference übergeben werden.
Es kann schon echt nerven, wenn jemand Dinge in etwas hineininterpretiert und einen dann über Sachen belehrt, die man eh schon weiss.

@Mathias: Für eine konsistente Strategie des Austausches von Error-State-Variablen ist das sicher ok mit by Reference. Ansonsten hast du wie bei starker Nutzung von by Reference ein Variablen-Scope Problem.
Variablen-Scope ist die Sichtbarkeit der Variable. Wenn du das Beschreiben von by reference übergebenen Variablen zur gängigen Coding-Praxis machst, wird es unübersichtlich.
Global Variablen werden zumindestens immer an einer dafür vorgesehenen Stelle explizit aufgelistet.
Wenn mehrere Programme/Funktionen innerhalb eines Programmes auf 1 gemeinsame Ressource (z.B. Variable) zugreifen, steht man immer vor dem Problem, den Zugriff zu ordnen.
Vermutlich hat wg. dieser Probleme Shared Mail in Lotus Notes nie funktioniert oder in .NET sollen wohl alle Ressourcen innerhalb der Anwendung beschrieben und wohl auch getan werden. Nix mehr Registry.
Letztendlich hat das alles glaub ich eine sehr gleiche gemeinsame Ursache.
Wenn ein Programm einen Win-Registry-Eintrag macht, geht es davon aus, dass kein anderes Programm mehr diesen Registry Eintrag überschreibt.
Wenn du in der main-Funktion eine andere Funktion aufrufst und nach der Rückgabe davon ausgehst, dass die andere Funktion eine bestimmte Variable geändert hat, ist das sogar noch gefährlicher.

So ungefähr jedenfalls.

Das und vieles mehr wird übersichtlicher und klarer als ich das je könnte in dem Buch "Code Complete" von Steve McConell beschrieben. Obwohl die meisten Beispiele in Pascal sind, ist es gut lesbar. Das Thema hier z.B. S. 216 ff.
Ich kann auch Java Programmierer nicht ernst nehmen, die sich an die dort aufgeführten Gesetze nicht halten. Beliebtes Thema ist z.B. Verzicht auf Kommentierung.
-> Warum programmierst du eine Objektorientierte Sprache?
<- Das ist übersichtlicher und man kann besser ändern, erweitern und wiederverwenden.
-> Und warum setzt du keine Kommentarzeilen?
<- Keine Zeit...

Suppä.


Gruß Axel

TMC:
Danke für Eure Infos, Anregungen und Hinweise auf die Gefahren.

Ich werde mir noch ein genaues Konzept überlegen, wie ich *durchgängig* alle Functions aufbaue.

Navigation

[0] Themen-Index

[*] Vorherige Sete