Was ein Notes-Entwickler immer beachten/machen sollte

[koehlerbv]

Keine Zeile LS-Code ohne ErrorHandler, der zumindest ErrorCode und ErrorLine ausgibt.
Konstanten auch als solche deklarieren (ggf. "Pseudo-Konstanten" verwenden) und diese an zentraler Stelle deklarieren.
(Also nicht Set viewLookup = dbCurrent.GetView ("(LookupView)"), sondern Const VIEW_LOOKUP = "(LookupView)" usw.)
Das FrontEnd immer an den üblichen Notes-Standards ausrichten (Funktionsweise, Beschriftung und Icons für Buttons usw.)
Keine UI-Klassen in Agents, die im Backend laufen werden.
Jeder LS-Routine einen aussagekräftigen Header verpassen, der Sinn und Zweck, Parameter und Rahmenbedingungen ausdrücklich erklärt - und diesen weiter pflegen !
Zwischenstände der Entwicklung permanent sichern - das rettet manchmal zig Stunden Entwicklungsarbeit.
Schon gesagt, aber m.E. wirklich wichtig: Felder, die nicht per @functions oder durch Interaktion mit dem User gefüllt werden, nicht in Masken aufnehmen. Falls erforderlich, diese als computed when composed deklarieren.
Wo machbar, Felder als computed for display deklarieren.
Ansichten so schlank wie nur irgend möglich halten und immer daran arbeiten, die Anzahl der Ansichten zu minimieren. Auch wenn das als Widerspruch erscheinen mag: Jede Ansicht, auf die programmatisch zugegriffen werden soll, als versteckte Ansicht erstellen.
Datenbank-Synopsen bei der Weiterentwicklung bereithalten. Teamstudio Analyzer wäre natürlich besonders fein ;-)
Subform-Anzahl pro Maske minimieren (Performance).

To be continued ...

Bernhard

[Ute]

nie die Servernamen in Masken, Feldern etc verwenden
immer serverunabhängig programmieren
Namenskonvention erarbeiten
Teilmasken für Änderungen in Standardschablonen verwenden
UNC Pfade verwenden

ein leidgeprüfter
Admin
Gruß
Ute

[Stefan1971]

Folgende Tatsache hat mich jetzt doch etwas überrascht:

http://www.geniisoft.com/showcase.nsf/archive/20040615-1118?OpenDocument&count=-1

Bis vorhin dachte ich, die Aufzählung bei der Definition von Variablen nimmt sich nichts gegenüber der (vermeintlich) "umständlichen" Einzelnennung.

Gruss, Stefan

[Semeaphoros]

Da kann man gewiss nicht häufig genug drauf hinweisen, dass da LS sich anders verhält als andere Sprachen .....

[koehlerbv]

.. aber eigentlich ist hier LS "sauberer": Ohne konkrete Ansage ist eine Variable eben Variant.
Die Variablendeklaration gehört also auch eindeutig in diesen BP-Artikel. Wobei in diesem Zusammenhang auch unbedingt stehen sollte:
- Option Declare / Explicit verwenden. IMMER !
- Keine Mehrfachdeklaration in einer Zeile (liest sich auch blöd sonst, und kostet oder spart keinen Speicherplatz)
- Variablenbezeichnungen nach der Hungarian Notation verwenden und nicht den uralten (und immer noch erlaubten) BASIC-Quatsch wie $, % oder & etc. verwenden.

Bernhard

[TMC]

- Option Declare hatten wir glaub ich hier schon öfter,aber egal, so vergessen wir es wenigstens nicht  

Zu Variablen-Präfixen gab es letztens auch eine interessante Diskussion im Rocky Oliver Blog.

Ich bin auch dafür dass man das wirklich immer Präfixe verwendet. Dass man da nun 1:1 die ungarische Notation verwenden sollte/muss würde ich jetzt nicht verpflichtend sehen. Ich bin auch wieder von sz als String-Präfix abgekommen und nehme lieber str.
Imho sollten wir aber im erklärenden Text dieses BP-Artikels zumindest Vorschläge auflisten und z.B. auf den Artikel der " The View" verweisen (Link).

Da als Ratschlag: Organisationsweit immer dieselben Präfixe. Wenn eine Organisation/Firma z.B. schon immer mit sz gearbeitet als Präfix für String, würde ich es als Fehler sehen, in einer neuen DB alle Strings mit "str" einzuleiten.

[koehlerbv]

str oder sz - das ist (unter den von Dir genannten Umständen) wirklich egal. Hauptsache, es wird in der Entwickler-Community, die da zusammen an Projekten arbeitet, EIN Standard verwendet. Die "Community" darf dabei auch auf einem einzelnen Mitglied beruhen ;-) Hauptsache, man weiss auch noch nach Jahren, was gemeint war.

Bernhard

[Semeaphoros]

• Dort, wo Lotus Präfixe in Templates verwendet (was leider nicht überall der Fall ist) wird str verwendet
• die neueren Stringfunktionen verwenden str als Präfix (strcompare zum Bleistift)
• Der erwähnte TheView Artikel verwendet str als Präfix
• C verwendet in der String-Library str als Präfix
• Java verwendet str als Präfix

Ich denke, da insbesondere auch in den Sprachdefinitionen str sich durchgesetzt hat, ist die Vorgabe gegeben.

[TMC]

Auch noch ein paar hilfreiche Infos zu diesem Thema:

http://www.nsftools.com/tips/PerfTips.htm

[wflamme]

Zu beachten:

There *are* users.

[TMC]

Ja, Wolfgang?

[wflamme]

Naja, also .... Nicht wirklich. Aber man sollte zumindest ab und an so tun, als wären da welche.

[-Michael-]

Negativbeispiel - Auszug aus der "SubmitForReview" - ScriptLib der R5-Schablone "Doc Library Notes&Web R5":

Code

Dim ReviewerNumber, TotalReviewers, Position, SubmitNow, NSubmitNow, IsCurrentReviewer As Integer
Dim ReviewerList, ReviewTime As Variant
Dim NextReviewer, DbName, ViewList, NotificationType, ClientType, FieldName, ErrorText As String

Soweit ich weiß werden dadurch alle Variablen als Variant deklariert, die nicht den Zusatz "As xyz" haben.

Was geht ist:

Code

Dim strEinString as string, iMeinInteger as Integer, straMeinArrayString() as String

Wundert mich eigentlich, dass gerade in einer von Iris / IBM ausgelieferten DB sowas vorkommt.....

[Semeaphoros]

Stimmt, das ist äusserst merkwürdig, Deine Bemerkung ist durchaus richtig