1. Schreiben Sie den ersten Buchstaben vom Klassennamen groß. Der ersten Buchstabe von Feldern, Methoden und Objekten sollte klein geschrieben werden. Bei allen Bezeichnern sollten die Wörter fortlaufend zusammenschrieben werden und der ersten Buchstabe in den dazwischenliegenden Wörter sollte groß geschrieben werde. Zum Beispiel:
   ThisIsAClassName
   thisIsAMethodOrFieldName
   Schreiben Sie alle Buchstaben der Bezeichner von Konstanten (static final) groß.
   Dies zeigt an, daß sie immer konstant sind, schon zur Zeit der Programmübersetzung.
   Packages sind ein Sonderfall! In den Bezeicher für Packages werden alle Buchstaben klein geschrieben, auch die Anfangsbuchstaben der dazwischenliegenden Wörter.
   Die Domäneerweiterung (com, org, net, edu, usw. ) werden auch klein geschrieben. ( dies war ein(dies war eine Änderung zwischen JAVA 1.1 und JAVA 1.2.)
1. Beim Erstellen einer Klasse für die allgemeine Verwendung, sollten Sie die "gebräuchlichen Vereinbarung" beachten und folgende Methoden definieren: equals( ), hashCode( ), toString( ), clone( ). Außerdem sollte Ihre Klasse die Schnittstellen (implements Cloneable) und (implements Serializable)Cloneable und Serializable implementieren.
1. Für jeden Klasse, die Sie erstellen, sollten Sie eine main() Methode vorsehen, die den Code zum testenTesten ihrer Klasse beinhaltet. Sie müssen diesen Test-Code nicht beseitigen, wenn Sie die Klasse später in einem Projekt verwenden. Bei Änderungen in der Klasse lassen sich diese dann wieder schnell testen. Dieser Code liefert auch ein Beispiel, wie Ihre Klasse anzuwenden ist.

4. Methoden sollten möglichst kurz gehalten werden, funktionellen Einheiten, die einen angeschlossenenkurze, funktionelle Einheiten sein, die einen in sich geschlossenen Teil einer Klassenschnittstelle beschreiben und implementieren. Idealerweise sollten Methoden kurz sein; wenn sie zu lang werden, dann sollten Sie nach einer Möglichkeit suchen, um diese in mehrere kürzere Methoden zu teilen. Das wirdaufzuteilen. Das tut auch der Wiederverwendbarkeit Ihrer Klasse guttun. (manchmal müssen Methoden groß sein, aber sie sollten trotzdem nur eine einzige Sache tun.)
6. Wenn Sie eine Klasse entwerfen, denken Sie über die Möglichkeiten nach, die Ihr Kunde bei der Anwendung dieseder Benutzer dieser Klasse hat (es sollte völlig klar sein, wie die Klasse anzuwenden ist) und denken Sie perspektivischvorausschauend an die Arbeiten, die bei Wartung und Pflege Ihres Code anfallen werden (Sie sollten die Art an Änderungen, die zukünftig gemacht werden vorausahnen, um diese zu erleichtern).
1. Versuchen die Klassen klein und konzentriert zu halten. Anhaltspunkte bei denen sich wahrscheinlich einzu halten und auf das wesentliche zu beschränken. Anhaltspunkte, die auf einen erforderlichen Neuentwurf einer Klasse andeutethindeuten sind:
   1) Eine komplizierte switch Anweisung: versuchen Sie Polymorphismus zu verwenden
   2) Eine große Anzahl an Methoden, die eine breite Skala verschiedenster Tätigkeiten
   abdecken:-> versuchen Sie die Klasse in mehrere aufzuspalten
   3) Eine große Anzahl der Mitgliedsvariablen (Klassenvariablen ?),von Attributen, die eine breite Skala verschiedenster Merkmale abdecken:-> versuchen Sie mehrere Klassen zu verwenden
2. Halten Sie Methoden und Variablen so privat(private) wie möglich. Wenn Sie einmal einen Teil Ihrer Bibliothek (eine Methode, eine Klasse, ein Feld) publiziert(public) haben, können Sie dies nie wieder zurück nehmen. Falls Sie es doch tun, werden Sie den bestehende Code anderer, die Ihre Klasse benutzen, zerstören und Ihn Zwingenzwingen sein Programm umzuschreiben und neu zu entwerfen. Wenn Sie nur das publizieren, was Sie müssen, dann können Sie alles ohne Sorgen ändern und sei es eine Designänderung. Diese istungestraft ändern und da Designs sich imLaufe der Zeit ändern, ist dies eine wichtige Freiheit. Das privat (private) HaltenPrivathalten von Dingen ist bei der Verwendung mehrerer threadsvon Multithreading besonders wichtig. Nur private Felder können gegen unsynchronisierte Zugriffe abgesichert werden.
3. Hüten Sie sich vor dem "Riesen-Objekt-Syndrom". Dies ist öfter ein Leideine Heimsuchung von "strukturierten" Programmierern, welche neu in der OOP sind und welche weiterhin strukturierte (prozedurale) Programme schreiben und diese dann in ein, oder zwei Riesenobjekte packen. Mit der Ausnahme von Anwendungen, die sich mit Fenstern beschäftigen (frameworks),Anwendungs.Frameworks, verkörpern Objekte Konzepte(Abstraktionen) in Ihrer Anwendung, und nicht die Anwendung selbst.
9. Wenn Sie etwas häßliches tun müssen, dann sollten sie dies zumindest lokal im Inneren der Klasse tun.
10. Immer, wenn man merkt,Sie merken, daß die Klasse sehr stark mit einer anderen verkoppelt ist, sollte man diesollten Sie innere Klassen (inner classes) verwenden, um dadurch entscheidende Vorteile bei der Kodierung und Wartung der Klasse zu erreichen.
    erreichen (siehe "Improving the code with a inner class" auf dieder Seite 605).
11. Verwenden Sie großzügig Kommentare und verwenden Sie die Syntax von javadoc, um die Programmdokumentation zu produzieren.erstellen.
12. Vermeiden Sie die Verwendung sogenannter "magischer Zahlen" (Nummerale). Das sind Zahlen(Numerale). Das sind Zahlen, die fest im Code eingetragen sind. Es wird ein Alptraum für Sie werden, wenn Sie diese ändern müssen, da Sie nie wissen werden was "100" bedeutetwerden, ob der Wert "100" "die Größe eines Feldes ", oder "etwas völlig anderes" bedeutet. Besser ist es, Sie erstellen eine Konstante mit einem aussagekräftigen Namen und verwenden diese Konstante überall in Ihrem Programm. Dieses macht das Programm leichter verständlichverständlicher und viel leichter wartbar.
13. Im Falle des Auftretens einer Exception in einem constructor,Konstructor sollte man diese Exception gleich wieder auslösen (throw new Exception). Wenn manweiterwerfen wenn sie innerhalb eines Konstruktors die Exception abfängt, dann kann es zu Fehlern kommen, da die den constructor aufrufende Methodeabgefangen wird und sie dazu führt, daß da Objekt nicht angelegt werden kann., so daß der Aufrufer nicht einfach blind weitermacht und denkt das Object wurde korrekt erzeugt.
14. Wenn Ihre Klasse eine SäuberungsaktionAufräumungsarbeiten benötigt, die in dem Moment aufgerufendurchgeführt werden soll, wenn der Benutzer Ihrer Klasse das Objekt dieser Klasse entfernt, dann setzen Sie den SäuberungscodeCode zum Aufräumen in eine einzelne und gut definiertewohldefinierte Methode namens cleanup(), so daß der Zweck der Methode völlig klar ist. Außerdem ist es günstig, wenn Sie ein boolean-flag in Ihrer Klasse plazieren, welches anzeigt ob das Objekt gereinigtaufgeräumt wurde. In der finalize() Methode dieser Klasse,finalize()-Methode dieser Klasse können Sie dieses dann prüfen, um sich zu vergewissern, daß das Objekt bereits bereinigt wurde und erzeugen eine von RuntimeException abgeleitete Exception falls das Objekt noch nicht gereinigtbereinigt wurde, um deneinen Programmierfehler anzuzeigen. Bevor Sie sich auf dieses Schema anwenden,verlassen, vergewissern Sie sich, daß finalize() auf Ihrem System korrekt arbeitet. ( Es könnte sein, das Sie System.runFinalizersOnExit(true) aufrufen müssen, um dieses Verhalten sicherzustellen.)
16. Wenn ein Objekt innerhalb eines besonderem UmfeldesGültigkeitsbereiches entfernt werden muß (durch andere Mechanismen als die garbage collection), dann gehen Sie folgendermaßen vor:
    Initialisieren Sie das Objekt und bei Erfolg springen Sie sofort in einen try finally Block, wobei im finally Blockfinally-Block die Anweisungen für das Objekt-Cleanup stehen sollte.Aufräumen des Objektes stehen sollten.
16. Wenn Sie die Methode finalize() bei der Vererbung überschreibenden, vergessen sieVerwendung von Vererbung überschreiben, vergessen Sie nicht super.finalize() zu rufen.aufzurufen. (dies ist nicht notwendig, wenn das Objekt aus Ihrer superclass stammt)
    Object die Basisklasse Ihres Objektes ist)
    Sie sollten super.finalize() als letztes in Ihrer überschrieben finalize() Methode aufrufen und nicht als erstes, um sicherzustellen, daß Grund-Klassenbestandteile (der Superklasse) noch vorhanden und gültig sind, falls Sie diese noch brauchen sollten.
17. Wenn Sie eine Collection mit fester Größe von Objektenmit festgelegter Größe erstellen, dann übertragen Sie diese in ein Feld (array)Array (besondere, wenn Sie diese Collection von einer Methode zurückgeben). Sie erhalten damit den für Array-Objekte integrierten Vorteil eine Typprüfung zur Zeit des Compilierens. Der Empfänger des Arrays muß dann die Objekte der Arrayfelder u. U. nicht mehr in seinen gewünschten Typ umwandeln (type casting) .
18. Bevorzugen Sie Schnittstellen (interface) vor abstrakten Klassen (abstract). Wenn sich herausstellt, dasdaß Ihre aktuelle Klasse eine Basisklasse werden könnte, dann sollte Sie zuerst versuchen eineversuchen, sie als Schnittstelle zu definieren und nur wenn Sie gezwungen sind Methodendefinitionen oder KlassenvariablenAttribute zu integrieren, dann sollten Sie die Schnittstelle in eine abstrakte Klasse umändern. Eine Schnittstelle versinnbildlicht das, was der Benutzer Ihrer Klasse tun möchte, während eine Klasse dazu neigt sich auf Implementierungseinzelheitenneigt, sich auf Implementierungsdetails zu konzentrieren.
19. Innerhalb eines constructors,Konstruktors sollten Sie tun nur das tun, was erforderlich ist, um das Objekt in einen richtigen Zustand zu bringen. Hüten Sie sich davor anderendavor, andere Methoden zu rufen (außer Methoden, die final methods),sind), da diese Methoden durch jemanden überschrieben werden können. Dadurch kann es zu unerwarteten Ergebnisse während der Abarbeitung eines constructorsKonstruktors kommen. ( siehe Abschnitt 7 für Details. )Kapitel 7 bzgl weiterer Details).
1. Objekte sollte nicht einfach nur einige Daten halten; sie sollten auch ein wohl definiertes Verhalten haben.
21. Bevorzugen Sie die Komposition, bevorwenn Sie selber neue Klassen aus bestehenden Klassen erzeugen. Sie sollten nur dann Vererbung verwenden, wenn es durch Ihr Design erforderlich ist. Wenn Sie dort Vererbung verwenden, wo Komposition auch funktionieren würde, wird Ihr Entwurf(Design) unnötig kompliziert.
22. Verwenden Sie Vererbung und Methoden-Überschreibendas Überschreiben von Methoden dann, wenn Sie Unterschiede in Verhalten der Objekte ausdrücken wollen und Felder, wenn Sie Unterschiede im Zustand ausdrücken wollen. Eine extremes Beispiel, was Sie nicht zu tun sollten, ist von unterschiedlichen Klassen zu erben, um Farben darzustellen zu können, statt einfach ein Feld "Farbe" zu verwenden.
23. Um eine sehr frustrierende Erfahrung zu vermeiden, vergewissern Sie sich, daß es zu einem Klassennamen auch nur eine Klasse irgendwo in Ihrem classpath gibt. Andernfalls, könnte der Compiler eine identisch benannte andere Klasse vor der eigentlich gewünschten finden. In diesem Falle wird der Compiler mit einer Fehlermeldung abbrechen, da die Klasse zwar identisch bezeichnet ist, aber unterschiedlichen Inhalt hat. Wenn Sie denken, daß Sie ein classpath Problemvermuten, daß Sie ein Problem mit dem classpath haben, dann sehen Sie zuerst nach, ob es vielleicht *.class Dateien mit gleichen Namen unter allen StartpunktenEinträgen Ihres classpaths gibt.
24. Wenn sie Ereignis Adapter "event adapters"Ereignisadapter in JAVA 1.1 AWT verwenden, dann könnte es sein, daß sieSie leicht in eine Falle tappen. Wenn Sie eine der Adaptermethoden überschreiben und Sie machen bei der Schreibweise einen Fehler, dann werden Siewird eine neue Methode hinzufügen,hinzugefügt, und nicht eine der bestehenden Methoden überschreiben. Dies ist jedoch absolut legal und so werden Sie keinerlei Fehler-MitteilungenFehlermeldungen vom Compiler, oder Laufzeitssystem bekommen. Trotzdem wird Ihr Code einfach nicht korrekt arbeiten.
25. Verwenden Sie DesignmusterDesign Patterns um "leere Funktionalitäten" zu vermeiden. Zum Beispiel, wennWenn beispielsweise nur ein Objekt Ihrer Klasse erzeugt werden darf, dann flüchten Sie sich nicht in Ihre Anwendung und schreiben einen Kommentar "Bitte nur eins davon machen." sondern hüllen Sie es in einmachen Sie einen Singleton ein.draus. Wenn Sie viel schmutzigenundurchsichtigen Code in dem Programmteil haben, welches Ihre Objekte erstellt, dann suchen Sie nach Erstellungsmustern (creational pattern) wie eine Fabrikmethodewie eine Erzeugungsmethode (Fabrikmethode), in welcher Sie die Objekterstellung kapseln können. Durch die Vermeidung leerer Funktionalität (naked functionality) wird Ihr Code nicht nur viel leichter verständlich und wartbar, sondern er wird auch kugelsicherer (niet- und nagelfest) gegen die gut vorbereiteten Wartungsmitarbeiter, die nach Ihnen kommen.nagelfest gegen die wohlmeinenden, die nach Ihnen kommen und den Code warten müssen.
27. Hüten Sie sich vor der "Analysen Lähmung".einer Lähmung bei der Analyse. Bedenken Sie, daß Sie gewöhnlich in Ihrem Projekt vorwärtskommen müssen, bevor Sie alles wissen werden und daß es meistens der beste und schnellste Weg ist, etwas über die unbekannten Faktoren herauszufinden, wenn man den nächsten Schritt vorwärts geht, statt zu versuchen alles vorher im Kopf zu lösen.
27. Hüten Sie sich vor verfrühter Optimierung. Machen Sie erst Ihre Arbeit,Bringen Sie den Code erst zum korrekten Funktionieren, dann machen Sie esihn schneller, aber nur wenn Sie müssen und auch nur dann, wenn es bewiesen ist, daß es einen Leistungsengpaß in einem speziellen Abschnitt Ihres Code gibt. Es sei denn Sie haben einenWenn Sie keinen Profiler haben, um einen Engpaß zu entdecken,sonst werden sieSie wahrscheinlich Ihre Zeit verschwenden. Ein unsichtbarer Kniffe zur Leistungssteigerung machen IhrenNachteil von Performancetricks ist, daß Ihr Code weniger verständlich und wartbar ist.
28. Bedenken Sie, daß Code viel öfters gelesen werden muß, als er geschrieben werden muß. Saubere Entwürfe machen es leicht die Programm zu verstehen,erlauben leichtverständliche Programme, aber Kommentare, detaillierten Erläuterungen und Beispiele sind unschätzbar. Sie helfen sowohl sich selbst als auch jeden anderen, der nach Ihnen kommt. Wenn Sie sonst schon nichts anderes werden sich selbst und jedem anderen der nach Ihnen kommt helfen. Nichts anderes, alsüberzeugen kann, die Enttäuschung nach einem erfolglosen Versuch, brauchbare Information aus der Online JAVA Dokumentation herauszuholen,Java-Dokumentation herauszuholen sollte dies tun.
29. Wenn Sie denken, dasdaß Sie eine gute Analyse, Design, oder Implementierung haben, dann machen Sie einen Probelauf (walkthrough).ein walkthrough (Review). Bringen Sie jemand von außerhalb Ihrer Gruppe herein. Es muß kein Gutachter sein, aber es kann jemand von einer anderer Gruppe innerhalb Ihres Unternehmens sein. Die Prüfung Ihrer Arbeitet aus einem Paaranderen frischen AugenBlickwinkel kann Probleme in einer Phase aufdecken, in der es viel leichter ist diese zu fixierenbeseitigen und Sie werden mehr Geld sparenZeit und Geld sparen, als Sie für die walkthrough-Phase aufwenden müssen.
30. Eleganz macht sich immer bezahlt. Anders gesagt, es dauert sicherlich viel länger um eine wahrlich graziöseelegante Lösung zu einer Problem zu erreichen, aber wenn es dann erstmals funktioniert, und der Code leichter an neue Situationen anpaßbar ist, statt unzähliger Stunden, Tage, oder Monate voller Mühe zu kosten, dann werden sieSie die Vorteile sehen (auch wenn dies keiner messen kann). Und es gibt kein vergleichbares Gefühl, als das, wenn man weis,weis, daß man ein verblüffendes Design hat. Erwehren Sie sich dem Drang zu schnell vorzugehen; er wird Sie nur bremsen.
31. Sie können einige andere Programmierrichtlinien im Internet finden. Mehrere gut Links finden sie unter: http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/mm-WebBiblio . htmlgute Links finden Sie unter:

http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/mm-WebBiblio.html

Falls sich bestimmte Begriffe nicht anderes klären lassen, bitte Mail an alle zur Klärung, z. B. Walkthrough, "nake functionality", etc.

Zu Punkt 25:

Ich glaube, daß Bruce mit "naked functionality" meint, daß man sich davor hüten sollte, nur die bloße Funktionalität zu implementieren, sondern auch etwas Komfort darumherum anzubieten. Beispiel: Einen Singleton zu erstellen wäre nicht unbedingt notwendig, wenn alle Benutzer sich daran hielten, nur eine Instanz zu erstellen. Der Singleton kann aber die Einhaltung dieser Regel garantieren.

Ja., sehr gut. In der derzeitigen Fassung macht der Punkt keinen Sinn.

Zu Punkt 29:

Walkthrough habe ich hier mal mit Review übersetzt, das kommt dem Sinn vielleicht am nächsten

Evtl. sollte man auch den Begriff stehen lassen, Walkthrough ist eigentlich schon einigermaßen gebräuchlich in diesem Umfeld, evtl. Code-Inspektion oder Code-Simulation

beide Begriffe kommen hoffentlich bald ins Lexikon.