Devcartes - Softwareentwicklung

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?

Empfehlungen: Exercism

Tristan — Thu, 04 Jun 2026 00:00:00 +0100

Quick Facts:

Anbieter: Exercism.org (gemeinnützig, Open Source)
Gründung: 2013
Sprachen: Über 70 Programmiersprachen – z.B. Python, Go, Rust, C# uvm.
Formate: Browser-basierte Aufgaben + Kommandozeilen-Tool
Besonderheit: 1:1 Mentoring durch erfahrene Entwickler:innen
Preis: komplett kostenlos
Link: exercism.org

Worum geht es?

Auf Exercism lernst du Programmieren durch praktische Übungen und wertvolles Feedback von erfahrenen Mentoren. Hier gibt es keine Videokurse oder Tutorials im eigentlichen Sinn, was aus meiner Sicht ein absoluter Vorteil ist und für die Plattform spricht.

Für wen ist die Plattform?

Ideal für:

Einsteiger, die nach den Grundlagen einer Sprache üben wollen
Fortgeschrittene, die eine neue Sprache schnell und idiomatisch lernen möchten
Autodidakten, die konstruktives Feedback vermissen

Du solltest mitbringen:

Grundlegendes Verständnis von Variablen, Schleifen, Funktionen (je nach Track unterschiedlich)
Motivation, Probleme selbstständig zu lösen
Englischkenntnisse (alle Aufgaben und Diskussionen sind auf Englisch)

Eher nicht geeignet, wenn:

Du einen klassischen Videokurs mit Dozent suchst
Du ein großes Projekt bauen willst (Exercism fokussiert kleine, isolierte Übungen)
Du keinen englischen Text lesen magst

Wie funktioniert es?

Exercism ist in sogenannte Tracks aufgeteilt, einen Track pro Programmiersprache. Jeder Track enthält Dutzende bis hunderte Übungen, sortiert nach Schwierigkeit.

Der typische Workflow:

Track auswählen: z. B. Go, Python oder Rust.
Erste Übung: meistens "Hello World", um die Umgebung zu testen.
Aufgabe herunterladen: entweder im Browser-Editor oder per CLI.
Code schreiben: bis alle Tests bestehen.
Lösung einreichen: optional mit einer Frage an den Mentor.
Feedback erhalten: meist innerhalb weniger Stunden bis zwei Tage.
Überarbeitung: basierend auf dem Feedback die Lösung verbessern.
Nächste Übung: der Track schaltet nach und nach neue Aufgaben frei.

Zusätzlich gibt es "Practice"-Übungen und "Concept"-Übungen (die ein bestimmtes Sprachfeature erklären, z. B. Slices in Go oder Pattern Matching in Rust).

Was lernst du?

Neben der Syntax einer Sprache, lernst du hier auch wie man idiomatischen Code schreibt. Hierbei helfen vor allem die sehr geduldigen und erfahrenen Mentoren.

Warum lohnt sich Exercism?

Sowohl Anfänger, als auch Profis können hier viel lernen und sich mit anderen austauschen. Jeder in seiner jeweiligen Geschwindigkeit und bis zu der Tiefe, die für ihn angenehm ist.

Bonus: Alles Open Source. Du kannst sogar eigene Übungen beitragen oder Fehler in den Aufgaben korrigieren.

Wie startest du am besten?

Meine Empfehlung für einen schnellen Einstieg:

Wähle eine Sprache, die du schon ein bisschen kennst – nicht die erste, die du lernen willst, sonst kämpfst du mit Syntax und dem Workflow.
Installiere das CLI-Tool (exercism auf der Kommandozeile). Das Browser-Interface ist okay, aber mit lokalem Editor (VS Code etc.) und echten Tests macht es mehr Spaß.
Setze dir ein wöchentliches Ziel: Zwei bis drei Übungen pro Woche sind realistisch, wenn du nebenbei arbeitest oder studierst.
Nutze das Mentoring aktiv – stelle deine Fragen so konkret es geht, denn je genauer deine Frage, umso besser das Feedback.
Schau dir nach dem eigenen Lösen die Community-Lösungen an – nachdem du deine Lösung eingereicht hast, werden dir oft andere Ansätze gezeigt. Fremden Code zu lesen und zu verstehen ist auch eine wichtige Fähigkeit für einen Entwickler.

Persönliches Highlight

Mein persönliches Highlight war der Rust-Track, hier sind vor allem die Mentoren, die ich bisher erlebt habe sehr ausführlich, geduldig und erfahren. Außerdem ist der Track sehr ausgereift.

Zum Schluss

Exercism ist eine echte Perle unter den Lernplattformen und meiner Meinung nach viel zu unbekannt.

Wenn dir die Seite also gefällt, dann lass den Entwicklern doch eine kleine Spende da oder hilf mit, indem du Dokumentation schreibst, Aufgaben verbesserst oder sogar neue einreichst. Oder empfehle sie einfach nur weiter.

Bist ein echter Profi in einer Sprache, dann könntest du auch als Mentor mithelfen.

Besucht auch gerne mein Exercism Profil und schaut euch meine Lösungen, Testimonials oder Contributions an.

Rusty Bytes: Traits und mehr

Tristan — Wed, 11 Mar 2026 00:00:00 +0100

Was sind Traits?

Traits sind Rusts Version von Interfaces. Ein Trait definiert eine Schnittstelle, eine Menge von Methoden, die ein Typ implementieren muss, außer es gibt eine Standardimplementierung. Wer schon mit Interfaces aus C#, Java oder Kotlin gearbeitet hat, kennt das Konzept.

trait Greet {
    fn hello(&self) -> String;
}

struct German;
struct English;

impl Greet for German {
    fn hello(&self) -> String {
        String::from("Hallo!")
    }
}

impl Greet for English {
    fn hello(&self) -> String {
        String::from("Hello!")
    }
}

Traits können auch eine Standardimplementierung mitbringen, die ein Typ überschreiben kann aber nicht muss:

trait Greet {
    fn hello(&self) -> String {
        String::from("Hi!")
    }
}

So weit, so bekannt.

Interessant wird es, wenn man Traits als Parameter verwendet, denn da beginnt die eigentliche Frage: Was passiert dann zur Compile-Zeit und welche Auswirkungen hat es auf die Laufzeit?

Monomorphisierung – Polymorphismus zur Compile-Zeit

Wenn eine Funktion einen generischen Typ mit Trait-Bound erwartet, erzeugt der Rust-Compiler für jeden konkreten Typ, mit dem die Funktion aufgerufen wird, eine eigene spezialisierte Version. Das nennt sich Monomorphisierung.

fn greet<T: Greet>(g: &T) {
    println!("{}", g.hello());
}

Der Compiler sieht, dass greet mit German und English aufgerufen wird, und erzeugt intern je eine Funktion für Englisch und eine für Deutsch:

fn greet_german(g: &German) { println!("{}", g.hello()); }
fn greet_english(g: &English) { println!("{}", g.hello()); }

Das ist gleichbedeutend mit dem impl Trait-Syntax, der etwas lesbarer ist:

fn greet(g: &impl Greet) {
    println!("{}", g.hello());
}

Vorteil:
Zur Laufzeit gibt es keinen Overhead. Der Compiler kennt den konkreten Typ, kann ihn inline optimieren und direkt den richtigen Funktionsaufruf einsetzen.

Nachteil:
Die Binärgröße wächst, denn für jeden Typ, mit dem die Funktion genutzt wird, landet eine eigene Kopie im kompilierten Code.

Dynamic Dispatch – Polymorphismus zur Laufzeit

Manchmal ist der konkrete Typ erst zur Laufzeit bekannt, so zum Beispiel wenn verschiedene Typen in einer Liste gesammelt werden sollen.

Hier kommt dyn Trait ins Spiel.

fn greet(g: &dyn Greet) {
    println!("{}", g.hello());
}

Statt einer spezialisierten Funktion pro Typ erzeugt der Compiler ein Trait Object. Das ist ein sogenannter Fat Pointer, der aus zwei Teilen besteht, einem Zeiger auf die Daten und einem Zeiger auf eine vtable.

Die vtable wiederum ist eine Tabelle mit Funktionszeigern für alle Methoden des Traits, wo zur Laufzeit die richtige Implementierung nachgeschlagen und aufgerufen wird.

let greeters: Vec<Box<dyn Greet>> = vec![
    Box::new(German),
    Box::new(English),
];

for g in &greeters {
    println!("{}", g.hello());
}

Das wäre mit Monomorphisierung nicht möglich, da der Compiler den Typ jedes Eintrags zur Compile-Zeit kennen müsste.

Vorteil:
Flexibel, kleinere Binärgröße, heterogene Collections möglich.

Nachteil:
Laufzeit-Overhead durch den vtable-Lookup, keine Inlining-Optimierungen möglich.

Wann was?

	`impl Trait` / Generics	`dyn Trait`
Auflösung	Compile-Zeit	Laufzeit
Performance	Höher	Etwas geringer
Binärgröße	Wächst pro Typ	Konstant
Heterogene Collections	✗	✓
Typinformation	Vollständig bekannt	Zur Compile-Zeit nicht bekannt

Als Faustregel gilt:

impl Trait ist der Standard
dyn Trait kommt zum Einsatz wenn der Typ erst zur Laufzeit bekannt ist oder eine heterogene Collection benötigt wird.

Fazit

Traits sind mehr als nur Interfaces. Die Entscheidung zwischen Monomorphisierung und Dynamic Dispatch ist eine Entscheidung zwischen Compile-Zeit-Garantien und Laufzeit-Flexibilität.

Im Vergleich zu Java oder C#, wo jeder Methodenaufruf über eine virtuelle Tabelle aufgelöst wird, gibt Rust einem die Wahl und man muss sich explizit entscheiden, was man möchte.

Explizit und ohne Overhead, sind zwei Grundprinzipien bei Rust, die man sich mit einer etwas steileren Lernkurve und mehr Boilerplate-Code erkauft.