Seitenhistorie
| Auszug | ||
|---|---|---|
| ||
Nuclos API Festlegungen: Benennung, insert, update, delete, Id, UID, Exception, Dispatch Thread, Code Style. |
Sprache: Deutsch · English
Festlegungen für Nuclos API Entwicklung
Konventionen für die Nuclos-API – Benennung von Methoden/Ids und Regeln für die Fehlerbehandlung.
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Auf dieser Seite
|
Diverse Festlegungen
Verbindliche Konventionen für die Entwicklung mit der Nuclos-API – für konsistenten, wartbaren Code.
Benennung
...
| Regel | Beispiel |
|---|---|
| Collections: Suffix |
...All() |
...
insert(BusinessObject) |
...
vs. insertAll( |
...
Collection<BusinessObject>) |
...
Löschen: delete |
...
nicht remove, drop |
...
| … |
Einfügen: insert |
...
nicht new, create |
...
| … |
Aktualisieren: update |
...
nicht modify |
...
| … |
Ids: Id statt ID |
...
getId() |
...
, Rückgabe-Methoden enden auf ...Id() |
...
| Id |
...
Fehlerbehandlung Exceptionshandling
Bitte immer folgendes beachten:
| -Datentyp | immer Long bzw. UID |
Fehlerbehandlung
- Exceptions nie still abfangen – mindestens
...
- eine Warnung ins Log
...
- schreiben.
...
- Auf dem Dispatch-Thread keine
RuntimeException(z.
...
- B.
CommonFatalException) werfen
...
- – das bringt die GUI zum
...
- Absturz
...
- /Einfrieren.
- Möglichst keine allgemeinen
Exception/RuntimeExceptionfangen; wenn nötig, so minimal wie möglich. - Lange Methodenketten vermeiden – sie sind schlecht zu debuggen und liefern nichtssagende Stacktraces.
| Info | ||
|---|---|---|
| ||
Beispiele für sauberen Stil: Code Style sowie schlecht → richtig. |
Verwandte Seiten
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.
Codeverdoppelung vermeiden
Blindes Copy & Paste von Code ist ein No-Go. Die Wartung ist eine Katastrophe, muss man was ändern, muss man erst alle Stellen zusammensuchen. Der Code bläht sich völlig unnötig auf. Nicht umsonst werden “Code duplicates” von IntelliJ angemeckert. Letztens wurde erst 20-fach kopierter Code aus den Sourcen entfernt.
Bitte Code-Verdoppelung in jedem Fall vermeiden und zwar:
1) Verwendung identischer Methoden in einer abstrakten Überklasse.
2) Falls 1) nicht möglich ist: Auslagerung in eine statische Methode in einer Utils-Klasse.
3) Falls Client und Server gleiches machen wollen: Auslagerung in den Common-Block.
Überblick
Inhalte