The Power of Ten

Coding Guidlines sind immer kontrovers. Wenn ein Team um ein neues Mitglied wächst, werden solche Guidlines immer wieder hinterfagt.

Der NASA Ingenieur Gerard J. Holzmann hat mit seinen Erfahrung The Power Of Ten formuliert. Code von NASA Ingenieure geht bekanntlich auf lange Reisen (z.B. Voyager 1+2).

Diese Guidlines sind zwar auf die Programmiersprache C ausgelegt, doch können sie sicher auch für Java adaptiert werden. Ist ja die Java Syntax ein C Derivat.

Avoid complex flow constructs

Diese Regel beschreibt, dass Sprungbefehle wie goto und recursion verboten sind. Java besitzt zwar das Keyword goto; ist aber nicht nutzbar. In Java wäre wohl ein `break ein Sprungbefehl

loops:
for (int i = 0; i < 3; i++) {
	if(foo()) {
		break loops;
	}
}

Diese Regel macht durchaus Sinn und würde ich allen Entwicklern empfehlen zu befolgen.

All loops must have fixed bounds

Klar, wenn wir einen Webserver schreiben, werden wir wohl einen unendlichen Loop haben. Doch auch dieser muss man abbrechen können. Sollte ein kill-Signal kommen, sollte man das Programm beenden (gracefull shutdown). Die NASA geht hier ja soweit, dass sie sagt, jede Schleife braucht ein Maximale ausführung. Also nur Maximal 2147483647 Request für ein Webserver. Danach starten wir also neu.

Ich empfehle daher, dass man sich bei jeder Schleife Gedanken machen soll, wieviel diese durchlaufen wird.

Avoid heap memory allocation after initialization

Nun sind wir bei einem Thema, welches sicher schwierig wird für OO-Sprachen mit grossen Frameworks. Generell sollte man unter Kontrolle über das Keyword new in Java haben. Factories welche Objekte generieren, sollten mit Vorsicht aufgerufen werden. Ich empfehle immer wiedermal das Beans-Konzept vom Spring-Framework zu studieren.

Sehr empfehlenswert sich diese Regel zu merken! Wird aber meist vom z.B. Spring-Framework gut gemacht.

Restrict functions to a single printed page

Ich versehe diese Regel so, dass man unnötige Abstraktion verhindern soll. Alle wichtigen Sachen beeinander und prägnant zusammen! Nicht im EE-Elfenbeintrum sterben. Mit gewissen Boilerplate-Code schafft man es leider nicht ganz auf eine Seite. Der NASA Ingeneur redet ja auch von Funktionen, und sieht da eine Grenze von 60 Zeilen.

Use a minimum of two runtime assertions per function

Muss ich gestehen, dass Assertion mir wenig in Java begegnet sind. Ich selber nutze sie nicht; kann aber nur den Artikel von Oracle empfehlen: Assertion Guide.

Restrict the scope of data to the smallest possible.

In der aktuellen Java Bewegung wird ja auch Immutability propagiert. Dazu verwendet man meist Java Records:

record Foo(String id, String name) {
}

Leider sind noch nicht alle Frameworks und Code-Analyser soweit mit dem neuen Sprachfeature umzugehen.

Check the return value of all non-void functions, or cast to void to indicate the return value is useless.

Ich bin voll Vertreter dieser Konvention. Lange Zeit wurde in der Java Welt propagiert, dass man Exceptions einfach weiter wirft - und sogar im Codeflow als return quasi verwendet. Erst ganz am Schluss sollte irgendwo im Framework dann das Error-Mapping stattfinden. Ich bin persönlich kein Fan davon. Erst neuerdings mit dem Druck von golang hat sich die Erkentnis durchgesetzt, dass schnelles Errorhandling von Vorteil ist. Mit der Einführung von Java Streaming API kann man auch gut mit Optional<Foo> als return value überlegen.

Use the preprocessor only for header files and simple macros.

Ganz klar ist Lombock als preprocessor gehört verboten :-). Im Java-Umfeld ist mit dem Spring Framework eher die Seuche der Profile gemeint. Jedes Profil gibt mir eine neue Ausprägung der Applikation. Diese sollte getestet werden. Also local, cloud, inmemory und prod Profil - gibt ja schon 4^2 Versionen, welche getestet werden müssten. Profilkombinationen die nicht erwünscht sind, muss man ausschliessen.

Limit pointer use to a single dereference, and do not use function pointers.

Alles in Java sind Referenzen. Ich denke da eckt man in der Java-Welt definitv an. Man will ja die Flexibilität haben. Sollte sich doch mal ein Satelit oder ein Mars-Rover mit Java schreiben lassen, würde ich bei dieser Regel argumentieren, dass man nicht Functional Interfaces brauchen sollte. Wobei gerade das ein Feature ist, welches mit Java Streaming API viel Datenmanipulationen erleichtert hat.

Compile with all possible warnings active; all warnings should then be addressed before release of the software.

Ich denke das kann man in Java bedenkenlos übernehemen.

Quellen