2.5 Programmierstandards

• Ein einheitlicher Programmierstil erleichtert die Wartung
• Programmierstandards sollten schriftlich festgehalten, und über Intranet verfügbar sein.
• Einhaltung von Programmierstandards nur durch gegenseitige Kontrolle möglich.
• Welcher Standard man wählt ist nicht so wichtig, wie daß der gewählte Standard einheitlich eingehalten wird.
• Es ist ausdrücklich erlaubt gegen Standards zu verstossen. Aber dann muss es im Code durch einen Kommentar begründet sein. Ggf. lohnt es sich sich mit anderen Programmierern zu beraten.
• Im Laufe des Projekts koennen Standards geandert, geloescht und hinzugefuegt werden.
• Je nach Projekt können Standards unterschiedlich sein.

Typische Standards und Beispiele

• Formatierungskonventionen
• Schliessende Klammer eines Blocks muss immer in derselben Hoehe der oeffnenden Klammer sein.
• Namenskonventionen
• Alle Oberflächenklassen sollen mit dem Prefix UI anfangen.
• Alle Methoden die einen booleschen Wert zurückgeben, und das Objekt selbst nicht verändern sollen mit einem Fragewort beginnen. (z.B istStatusBeendet)
• Dokumentationskonventionen
• Methoden sollten i.a. nicht dokumentiert werden.
• Eine Klasse soll mit max. 3 Saetzen beschrieben werden. Jede Instanzvariable sollte mit einem kurzen Satz beschrieben werden.
• Programmierkonventionen
• Fange Exceptions nie mit leeren catch()Blöcken auf
• Benutze Exceptions nur für unerwartete Fehler, die selten auftreten.
• Benutze equals(), und nicht == um auf Gleichheit zu testen.
• Nachdem Erzeugen eines Objekts mit Constructor, muss das Objekt immer in einem gültigen Zustand sein.
• Packagingkonventionen
• Klassen die gegenseitig voneinander abhängig sind, sollten in einem Package sein.
• Ein Package das sehr schwer veränderbar ist, sollte nicht von einem Package abhängig sein, das sehr leicht veränderbar ist.

Für die meisten Sprachen gibt es StyleGuides, die sich als sinnvoll erwiesen haben.

Beispiel Java: