Diverse Festlegungen

• Sind Collections betroffen, sollten die Methodennamen ein "...All()" im Namen haben, z.B. insert(BusinessObject) - insertAll(Collection <BusinessObject>)
• Standardbenennung für Löschmethoden: delete (nicht remove, drop, etc.)
• Standardbenennung für Einfügemethoden: insert (nicht new, create, etc.)
• Standardbenennung für Aktualisierungsmethoden: update (nicht modify, etc.)
• Thema Id's:
  
  • Id statt ID (z.B. getId())
  • Methoden die allgemein eine Id zurückgeben sollten auch auf "...Id()" enden
  • Id's müssen immer vom Datentyp Long/UID sein
• Zusammenspiel Service - Provider...

Fehlerbehandlung Exceptionshandling

Bitte immer folgendes beachten:

1) Keine Exception still abfangen. Es muss immer wenigstens eine Warnung ins Log geschrieben werden.

2) Auf dem Dispatch Thread keine RuntimeException (z.b. CommonFatalException) werfen. Das bringt die GUI zum Komplett Absturz und Einfrieren.

3) Möglichst nicht allgemeine Exceptions "Exception/RuntimeException" catchen. Manchmal lässt sich das nicht ohne viel Aufwand vermeiden, das sollte aber in jedem Fall minimal gehalten werden. Am Besten gar nicht machen.

In diesem Zusammenhang bitte sog. lange Methoden Ketten vermeiden. Solche Ketten sind ganz schlecht zu debuggen und bei Stacktraces hat man keine Ahnung, was genau passiert ist. vgl. Java-Programmierstil Richtlinien für Nuclos

Datentypen für Ganzzahlen und FIießkommazahlen

Bei der Entwicklung sollte darauf geachtet werden, dass für Zahlen (Number) nur noch folgende zwei Datentypen verwendet werden:

• Long für Ganzzahlen
• BigDecimal für Fließkommazahlen

Long liegt zur Zeit der 64-bit Rechner und 64-bit Systeme nahe, da diese gegenüber dem 32--bit-Integer keinerlei Nachteile haben und einen wesentlich größeren Zahlenraum abdecken. 32-bit Integer sollte, wenn überhaupt, nur noch ausschließlich für Schleifenvariablen (i,j, etc..) verwendet werden. Rückgabewerte, Keys, Daten und alle Zahlen mit denen gerechnet wird, sollten immer Long sein.

BigDecimal ist unbedingt Double zu bevorzugen. Double ist von der Genauigkeit limitiert und kann bei Rundungen von Zwischenergebnissen für erhebliche Probleme sorgen. BigDecimal benötigt zwar mehr Ressourcen als Double, das hat aber für die typischen kaufmännischen Berechnungen in Nuclos kein merklichen Auswirkungen.