Best Practices > Diskussionen zu Best Practices

Was ein Notes-Entwickler immer beachten/machen sollte

<< < (5/7) > >>

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete