Warum die langen Namespaces?

Das hat technische Gründe, die im Aufbau von The Fluent Developer liegen. The Fluent Developer ist ein einziges großes Software-Projekt, in dem in einem Quellverzeichnis content sämtliche Texte und Codebeispiele liegen. Das ist so, damit ich auf möglichst einfache Weise im Text Quellcode und die Ausgabe der Beispielprogramme zeigen kann.

Ich habe früher Bücher in Word schreiben müssen, weil das die Verlage so wollten. Da war es immer ein Albtraum, Codebeispiele und deren Ausgaben in den Text zu kopieren, vor allem wenn man dann später noch Änderungen am Code vornehmen wollte. Wenn Du in einem Buch mal fehlerhafte Codebeispiele gefunden hast, dann weißt Du jetzt, warum das so ist.

Für The Fluent Developer habe ich das Einfügen von Codebeispielen in den Text vollständig automatisiert. In der Tat gibt es da sogar ein cleveres Caching, dank dessen Beispielcode nur dann erneut ausführt wird, wenn er geändert wurde. Ansonsten wird das gecachte Ergebnis verwendet.

Das hat beispielsweise den Vorteil, dass ich mein PHP auf eine neue Version aktualisieren und damit, indem ich den Cache lösche, auf einen Schlag alle Beispiele neu ausführen kann. Falls dabei einzelne Beispiele fehlschlagen, weil sie nicht mit der neuesten PHP-Version kompatibel sind, erkennt das die Plattform. Deshalb enden die Dateinamen mancher Beispiele auf -will-fail.php. Daran erkennt The Fluent Developer, dass der Fehler "Absicht" ist. Programme, deren Name nicht auf -will-fail.php endet, müssen ohne Fehler durchlaufen.

Mehrdeutige Namen

Aber zurück zu den Namespaces: da ich versuche, in Codebeispielen möglichst einfache Namen und Bezeichner zu verwenden, gibt es quer durch The Fluent Developer beispielsweise eine Vielzahl von Klassen, die den Namen Something tragen. Hinzu kommt, dass ich oft Quellcode von Seite zu Seite schrittweise weiterentwickle, das bedeutet, dass es in benachbarten Verzeichnissen verschiedene Versionen von Klassen gleichen Namens gibt. Jede IDE flippt dabei total aus, Autocomplete funktioniert nicht mehr richtig, man wird ständig angemault, dass es mehrdeutige Namen gibt, und so weiter.

Genau dieses Problem wird durch Namespaces gelöst.

Da ich ein großer Freund von Konsistenz bin, wollte ich ein einheitliches Schema für die Namespaces in meinen Beispielen haben. Was liegt also näher, als die Verzeichnisnamen direkt in einem Namespace zu übersetzen? So kann ich für jedes Codebeispiel automatisiert überprüfen, ob es den richtigen Namespace hat.

Da die Verzeichnisnamen auch SEO-Zwecken dienen und daher möglichst sprechend sind, werden die Namespace-Namen in den Beispielen sehr lang. Das ist sozusagen ein notwendiges Übel, das wir alle in Kauf nehmen müssen.

In einem regulären Software-Projekt würde ich die Namespaces allerdings nicht so tief verschachteln, sondern deutlich flacher halten.