Es ist eine schwierige Zeit heutzutage. Besonders für Software-Entwickler. Denn heutzutage gibt es für einen Software-Entwickler viele Dinge, die er lernen, können und beachten muss. Da gibt es die Tools, die Programmiersprachen, die Methoden, die Anforderungen, die Domäne, die Kollegen und noch vieles mehr. Da gibt es schon einmal Momente, in denen man sich unsicher ist. „Mache ich das richtig?“, „gibt es bessere Lösungen?“ oder „hoffentlich passt das…“. Zumindest geht es mir manchmal so, z.B. bei neuen Dingen oder besonders komplexen Problemstellungen. Ich bin dann froh, wenn ich um mich herum jemanden habe oder finde, der mich und mein Problem versteht und mir helfen kann. Helfen mit seiner Einschätzung, seiner Meinung und seinen Erfahrungen.

Helfen ist schön, geholfen werden ist schöner!

Ich weiß es nicht genau, aber ich vermute es ein wenig, dass Thomas auch froh ist, wenn er durch Meinungsaustausch seine eigenen Herausforderungen besser einzuschätzen vermag. Ich persönlich empfinde diese „Kalibrierung“ als wichtigen Baustein zur Festigung der eigenen Meinung.

Thomas hat mit Null Verständnis gefragt, wie die Handhabung von NULL als Rückgabe von Methoden bei anderen Entwicklern umgesetzt und eingeschätzt wird. Viele haben kommentiert, einige haben auch Blog-Post-Antworten geschrieben. Ich habe das mit Kommentaren und dem Null Toleranz-Beitrag auch getan, der unermüdliche Ralf hat auch kräftig in die Tasten gehauen. Überraschenderweise mit mehreren Aussagen.

Ralf geht in seinem „Plädoyer für Regeln“ auch auf einige Punkte ein, die ich über die Handhabung von NULL in Anwendungsszenarien bemerkt hatte. Ralf hat so vieles geschrieben, dass es mir schwer fällt, wirklich alle Themen in einem oder mehreren Blog-Posts zu erwidern. Einen Überblick über meine Perspektive möchte ich dennoch geben.

Mind the Null!

Ralf stellt im Namen der Community die erste Null-Regel auf:

“Man darf Null benutzen und auch als Wert zurückgeben – aber Vorsicht! Erst prüfen, ob es nicht auch anders geht”

D’accord! Das hatte ich ja auch schon in Kommentaren und per Twitter erwähnt. Doch wann kann man Null verwenden, wann nicht? Gibt es dafür eine „kontextarme“ Regel? Kann man pauschal sagen: „Verwende es nicht!“. Meiner Meinung nach ist das nicht so einfach. Klar kann ich auch sagen, dass man Null einfach nicht anwenden soll, aber ich mache es mir nicht so einfach.

Wenn ich nämlich obige Regel einem Embedded-Entwickler entgegenbringe, dann lacht der mich mal gepflegt vor seinen Kollegen aus. In der Embedded-Entwicklung, wie auch bei sehr ressourcenintensiven Geschäftsanwendungen ist es nämlich durchaus erstrebenswert, oft NULL zurückzugeben, um damit z.B. eine leere Liste oder leere Suche zu signalisieren. Es mögen sich wenige daran erinnern, aber NIL (als Synonym für NULL) ist die Abkürzung für „Not-In-List“.

Null für Hacker

Ich selbst durfte schon mehrere serverseitige Komponenten von „Exception-Flut“ befreien, in dem ich sie in einigen Stellen durch NULL ersetzt habe. Danach lief der Service doppelt so schnell bei 25% weniger Ressourcenverbrauch. Bin ich jetzt ein Aussetziger, weil ich die Regel nicht befolgt habe?

Ich denke nein. Denn: In einigen Anwendungsszenarien ist es gang und gäbe NULL als Mittel einzusetzen. Mehr noch, es ist „normal“, soz. “die Regel”. Deswegen sage ich nach wie vor: Die Regel ist richtig, man sollte vorsichtig mit NULL umgehen und es mit bedacht einsetzen. Doch eine „Faustregel“ ist es für mich noch nicht, denn man kann es (noch) in bestimmten Anwendungsfällen vorteilhaft und stringent einsetzen.

CatastrophicFailureException ?? Null

Ralf schreibt:

„Null-Regel #2 (von Ilker; noch zu diskutieren): In Katastophenfällen darf Null zurükgegeben werden.“

Das ist keine Regel. Den Regelbedarf und die Kreativität zum Design eines Regelwerks wie Ralf habe ich (noch) nicht. Ich habe dafür aber Programme, die Probleme lösen. Bei einigen, wenigen Programmen habe ich NULL als Rückgabe für „katastrophale Fehler“ zurückgegeben.

Das hat mir bei der defensiven Programmierung geholfen, denn es ging um eine etwas kritischere Komponente, die an Schnittstellen sog. „Guards“ hatte, die alle möglichen Exceptions abgefangen haben. Im Nachhinein betrachtet hätte ich es wohl auch mit einer „CatastrophicFailureException“ oder mehreren, spezifischeren Exceptions lösen können. C’est ca!

Null nur bei „gleicher Kategorie“

Die dritte Regel von Ralf:

“Null darf nur Rückgabewert sein, wenn Null zur selben Kategorie gehört wie ein Nicht-Null Rückgabewert”.

Naja, streng genommen ist NULL ja nichts, und damit kann man es auch nicht kategorisieren. Antizipieren kann ich da nur, dass es um das Beispiel von Thomas mit der Liste gehen kann. Dem kann ich nur zustimmen. Hier ist ein Ausnahmefall zwar auch möglich, aber doch eher selten.

Dein Pflock ist mein Maibaum!

Ralf hatte mir zu viel “Rumgeeiere” in meinen Aussagen über NULL attestiert. Das will ich doch gerne versuchen besser zu machen und Ralf‘s „Pflock in Boden“ in meine triviale niederbayrische Welt übertragen und damit mal den „Maibaum ins Dorf“ stellen. Also, auf geht’s, Maderl & Buam – mein Maibaum im Dorf „Nullinger“!

Ilker’s Statement zu Null als Rückgabe von Methoden:

NULL ist gefährlich, meide NULL, außer es gibt triftige Gründe. Triftige Gründe können Performance, Speicher oder dynamische Datenstrukturen sein. Solltest Du NULL als „Indikator“ für etwas verwenden (z.B. „Nicht gefundener Benutzer“), ziehe eine Vermeidungsstrategie mit Exceptions oder ReturnCodes in Erwägung. Sei auf der Hut, NULL ist überall. Prüfe, ob deine Parameter oder deine Methoden NULL zurückgeben. Prüfe besonders, wenn Du parallelisierst oder wichtige Schnittstellen bedienst. Solltest Du ein NULL finden, versuche zunächst damit umzugehen. Geht das nicht mehr, signalisiere die Ausnahme. Achte darauf, dass ein NULL die Methode nicht verlässt.

So, ich hoffe das war konkret krass korrekt genug!

Immer diese Abhängigkeiten

Nachdem nun der Maibaum in Django Asül-Manier aufgestellt ist, möchte ich neben dem Ausgangsthema mich noch ein wenig den neuen Themen widmen, die Ralf in seinem Rules of Null-Post erwähnt hat. Ralf regt sich dabei ganz besonders über die „It depends“-Phrase auf. Ja, „It depends“, die allmächtige und einzige Antwort auf alles, was so im Leben an Fragen auf einen zukommen kann. Die Antwort „It depends“ ist kurz, erfüllt die Aufgabe und ist hochgradig flexibel bei gleichzeitig maximaler Wiederverwendbarkeit. Geradezu traumhafte Eigenschaften aus der „Nerd-Software-Entwickler“-Perspektive, oder nicht? Vielleicht ist es deshalb auch so beliebt in unserer Banche?

Spaß beiseite. „It depends“ ist eine Phrase, die mehr oder minder Inhalt liefern kann. Ich stimme Ralf zu, wenn er sagt, dass dieses „Es kommt drauf an“-Getue mit der Zeit nicht mehr auszuhalten ist. Deswegen kann ich die Reaktion von Ralf auch gut verstehen. Ich selbst finde es teilweise immer wieder erschreckend, wie oft auf diese Floskel zurückgegriffen wird, ohne darüber nachzudenken. Dennoch verwende ich es – ab und an zumindest, wenn ich es für erwähnenswert erachte.

Niemals ist niemals niemals

Fakt ist auch, dass „It depends“ nicht nur eine Bierdeckelweisheit ist, sondern auch als Abkürzung verwendet wird. Im Stile „ich erspare mir und Dir jetzt nähere Details“. Das kann gut und schlecht interpretiert werden. So oder so, es kommt darauf an Genauer gesagt, auf den, der es interpretiert.

Womit wir bei der Quadratur des Kreises angelangt wären: Es ist nunmal so, dass wir Systeme vereinfachen und Abstraktionen schaffen, um es zu verstehen. Dabei geht auch Genauigkeit und Wahrheit verloren. Manchmal sogar so sehr, dass die aus der Vereinfachung abgeleitete Erkenntnis nicht mehr adequat bzw. erwartungsgerecht ist. Insofern ist „It depends“ nicht nur eine Fassade oder Ausrede, sondern eine zuweilen notwendige Mahnung, den Kontext und die Erkenntnis zu hinterfragen, sich bewußt mit der Lösung und Problemstellung auseinanderzusetzen. Für die Agilisten unter uns: „It depends“ ist ein auch ein Aufruf zum „Inspect & Adapt“.

Ich kann mich guten Gewissens Ralf anschließen, wenn es darum geht, Leitfäden und Empfehlungen über die Anwendung von NULL mit der Community zu erarbeiten. Meinungsaustausch ist Katalysator für Lernen, Entdecken, Erfahren und Bestätigen. Doch ein Regelwerk will ich nicht erstellen. Ich gebe meine Meinung und meinen Standpunkt gerne wieder. So wie ich es erfahren habe und so, wie ich es für gut empfinde.

Regeln habe ich auch. Ich habe meine eigenen Regeln, ich habe Teamregeln und ich habe noch eine Reihe weiterer Regeln, die ich für mich beachte und schätze. Regeln sind für mich wichtig. Ich möchte damit sagen, dass ich durchaus Ralfs Motivation nachvollziehen kann. Doch ich habe meine Beiträge nicht mit dieser Motivation mit der Community geteilt. Mein Ziel ist die Kommunikation und der Erfahrungsaustausch. Das wird auch so bleiben.