Godot jenseits von Spielen: Intro

Tristan — Thu, 01 Oct 2026 00:00:00 +0000

Einleitung

Eine Game Engine nutzen, um eine Desktop Anwendung zu schreiben?

Klingt auf den ersten Blick abwegig, aber gerade Godot eignet sich aus mehreren Gründen extrem gut dafür.

Warum Godot

Dass man ausgereifte und komplexere Desktopanwendungen mit Godot bauen kann, zeigt der Editor für die Godot Engine, der nämlich ebenfalls in Godot geschrieben ist. Außerdem hat Godot eine sehr gute Crossplattform-Unterstützung, was man auch daran sieht, dass der Editor sowohl im Browser, als auch für mobile Endgeräte zur Verfügung steht. Gerade auch die geringe Größe der ausführbaren Dateien macht Godot zu einer interessanten Engine für mobile Geräte und das Web. Auch GUIs lassen sich mit dem Editor oder dynamisch aus dem Code sehr einfach bauen und zwar ohne großen Aufwand responsive. Das ist bei anderen etablierten Desktop-GUI-Frameworks (z.B. Delphi oder .NET) nicht immer so einfach. Wer Bedenken wegen der Ressourcennutzung hat, für den hat Godot einen Low Processor Mode, der dafür sorgt, dass das Bild seltener und nur bei Bedarf erneuert wird.

Proof of Concept

Ich schreibe aktuell eine kleine Desktopanwendung mit Godot, die in erster Linie als Proof of Concept (PoC) gedacht war, sich mittlerweile aber als sehr nützlich für mein Studium erwiesen hat.

KOReader, eine beliebte eBook-Lese-App, speichert Lesestatistiken, Notizen und Highlights in einem bestimmten Format, die ich exportieren, aufbereiten und später zum Nachschlagen nutzen möchte.

Beispiel-Export

Am Ende soll eine Datei herauskommen, die in etwa so aussieht, wie der beispielhafte Ausschnitt aus dem Buch What is it like to be a bat von Thomas Nagel. Um den Text soll es an dieser Stelle aber überhaupt nicht gehen, es sind auch keine echten Highlights oder Notizen, sondern nur Beispiele.

Title: What Is It Like to Be a Bat? / Wie ist es, eine Fledermaus zu sein?

Author: Thomas Nagel

===========================================================================

Page 7 (yellow)
Das Thema ›Bewusstsein‹ macht das Leib-Seele-Problem praktisch unlösbar.

===========================================================================

Page 8 (yellow)
Es ist höchst unwahrscheinlich, dass irgendeines dieser mit dem Leib-Seele-Problem nicht verwandten Beispiele erfolgreicher Reduktion die Beziehung zwischen Psyche und Gehirn erhellen wird.

===========================================================================

Page 47 (yellow)
But no matter how the form may vary, the fact that an organism has conscious experience at all means, basically, that there is something it is like to be that organism.

===========================================================================

Page 53 (yellow)
Yet if I try to imagine this, I am restricted to the resources of my own mind, and those resources are inadequate to the task.

===========================================================================

Page 55 (purple)
Our own experience provides the basic material for our imagination, whose range is therefore limited. It will not help to try to imagine

---------------------------------------------------------------------------
Note:
Das ist eine Notiz von mir an mich
---------------------------------------------------------------------------

===========================================================================

Erklärung zum Export

Ich färbe meine Highlights und Notizen immer mit bestimmten Farben, die alle ihre eigene Bedeutung haben, um sie später einfacher zuordnen zu können.

So kann ich ohne großen Aufwand und mit minimaler Unterbrechung Notizen beim Lesen machen und habe diese später in einer einfachen und sortierten Form vorliegen, die ich entweder ausdrucken oder digital weiterverwenden kann. Durch die Seitenzahlen finde ich die Textstellen schnell wieder.

Zum Ende

In diesem Artikel bin ich auf das Was und Warum eingegangen. In den folgenden Artikeln werde ich auf das Wie eingehen und Wo Godot nicht die passende Wahl ist.

Guard Clauses

Tristan — Sun, 23 Aug 2026 00:00:00 +0100

Einleitung

Softwareentwickler aller Erfahrungsstufen, weltweit kennen das Problem:
Man schaut sich Code von Kollegen oder eigenen, älteren Code an und hat keine Ahnung, was dieser eigentlich macht. Er ist so tief verschachtelt und nimmt so viele Abzweigungen, dass man überhaupt nicht mehr weiß, welches Kriterium nun zum Abbruch der Funktion geführt hat oder welchen Wert eine Variable zu Zeitpunkt des Ausstiegs hat.

Viel schöner wäre es doch, wenn man seine Funktion lesen könnte wie ein Buch, von oben nach unten, und dabei auf einen Blick erkennen kann, an welcher Stelle die Funktion vorzeitig verlassen wird und warum.

Eines der Werkzeuge, auch Patterns genannt, in der Softwareentwicklung, das genau diesem Zweck dient, nennt man Guard Clauses.

Sie machen deinen Code sowohl lesbarer und wartbarer als auch robuster.

Was sind Guard Clauses

Guard Clauses (ins Deutsche frei übersetzt Schutzklausel), sind ein Pattern, bei dem man frühzeitig aus einer Funktion aussteigt, wenn eine bestimmte Bedingung eintritt, die die weitere Abarbeitung des Codes unnötig macht.

Das Prinzip ist, dass man Ausnahmen zuerst behandelt und dann den eigentlichen Programmfluss.

Entscheide selbst, welchen der beiden folgenden Codeabschnitte du lesbarer findest:

if user.is_logged_in {
    if user.has_permission {
        if user.name == "Max" {
            // logik kommt hier
        }
    }
}

if !user.is_logged_in { return; }
if !user.has_permission { return; }
if user.name != "Max" { return; }
//logik kommt hier

Wichtig! Die Bedingungen der Guard Clauses sind logisch negiert, da wir prüfen, wann wir nicht weitermachen dürfen.

Wann solltest du Guard Clauses nutzen

Wenn dein Code zu tief verschachtelt ist
Bei Vorbedingungen (Preconditions), die den Rest der Funktion hinfällig machen (z.B. Null-Checks)
Wenn die Ausnahmen klar vom Normalfall abgegrenzt werden können
Wenn du Code von oben nach unten lesen willst, wie ein Buch

Wann solltest du Guard Clauses nicht nutzen

Wenn es nicht den einen Normalfall gibt, sondern mehrere gleichwertige Zweige
- z.B. wenn je nach User-Rolle unterschiedliche Logik ausgeführt werden soll (Zweige sind gleichwertig)
Wenn es viele Vorbedingungen (mehr als 5 - 6) gibt, dann lohnt es sich in eine eigene Validierungsfunktion auszulagern

Best Practices

Guard Clauses am Anfang der Funktion bündeln
Eine Bedingung pro Guard Clause
Aussagekräftige Fehler zurückgeben oder sauberes Logging statt stiller returns
Guards nicht schachteln
Reihenfolge nach Wahrscheinlichkeit, statistisch häufige Fehler zuerst prüfen
Trotzdem das Single Responsibility Principle einhalten
In Teams das Pattern klar als Standard definieren, das spart Zeit und Diskussionen im Code Review

Schluss

Du siehst also, Guard Clauses sind ein sehr einfaches und nützliches Pattern, um deinen Code zu verbessern. Sie reduzieren Verschachtelung und erhöhen somit die Lesbarkeit.

Doch trotz der Einfachheit nutzen nicht alle erfahrenen Entwickler sie.

Was denkst du, woran liegt das?
Liegt es vielleicht daran, dass viele Entwickler mit if-else-Verschachtelungen groß geworden sind und Guard Clauses sich fremd anfühlen?

Devcartes - Praxis

Godot jenseits von Spielen: Intro

Einleitung

Warum Godot

Proof of Concept

Beispiel-Export

Erklärung zum Export

Zum Ende

Guard Clauses

Einleitung

Was sind Guard Clauses

Wann solltest du Guard Clauses nutzen

Wann solltest du Guard Clauses nicht nutzen

Best Practices

Schluss