Godot hat keine standardmäßige Code-Review-Checkliste. Die Engine hat einen Style Guide, ein Warnsystem und PR-Review-Richtlinien für Engine-Contributor. Aber wenn Sie mit einem kleinen Team oder allein ein Spiel entwickeln und Code auf GitHub pushen, gibt es keine kanonische Ressource nach dem Motto „das hier vor dem Merge prüfen“.
Genau das ist diese Ressource.
Jeder Check unten basiert auf der offiziellen Godot-4.6-Dokumentation. Wo ein Check sich auf eine bestimmte Doku-Seite bezieht, ist sie verlinkt. Die Checkliste ist in sechs Kategorien gegliedert, die die häufigsten Probleme abdecken, die wir in Godot-Pull-Requests sehen — besonders in Projekten mit KI-gestützter Entwicklung, wo Muster aus der falschen Version und plausibel wirkender, aber kaputter Code regelmäßig auftauchen.
Nutzen Sie sie vor dem Merge. Drucken Sie sie aus. Legen Sie sie in die CONTRIBUTING.md Ihres Repos. Oder setzen Sie Surmado Code Review auf das Repo an und lassen Sie Scout den Diff automatisch prüfen.
1. Versionskorrektheit
Ist dieser Code tatsächlich für Godot 4 geschrieben?
Das ist die wichtigste Kategorie für jedes Projekt mit KI-Unterstützung. LLMs sind mit jahrelangen Godot-3-Tutorials, Forenantworten und Dokumentationen trainiert. Sie produzieren mit großer Selbstsicherheit Godot-3-Code in einem Godot-4-Projekt. Der offizielle Migrationsleitfaden listet Hunderte von Umbenennungen und Breaking Changes auf. Der eingebaute Projekt-Konverter fängt viele davon ab, aber Godots eigene Dokumentation warnt, dass migrierte Skripte wahrscheinlich weiterhin Fehler enthalten und ein Großteil des Upgrades manuell bleibt.
Selbst nach der Migration kann KI alte Muster in neuen Dateien wieder einführen. Diese Kategorie erfasst sowohl Legacy-Code als auch frisch generierten KI-Code, der von der falschen Version gelernt hat.
Check: Sind alle Node-Klassennamen aktuell? Suchen Sie nach umbenannten Klassen. Die häufigsten:
KinematicBody2D→CharacterBody2DKinematicBody→CharacterBody3DPosition2D→Marker2D,Position3D→Marker3DSpatial→Node3DSprite→Sprite2D
Die vollständige Umbenennungsliste steht in den Migrationsdocs.
Check: Sind die Methodensignaturen aktuell? Mehrere häufig genutzte Methoden haben ihre Signatur geändert oder wurden umbenannt:
move_and_slide()nimmt keine Argumente mehr entgegen. Sie liest aus der eingebautenvelocity-Property des Nodes. (CharacterBody2D-Docs)instance()→instantiate()set_shader_param()→set_shader_parameter()map_to_world()→map_to_local()(GridMap und TileMap)change_scene()→change_scene_to_file()Thread.start(self, "__method", args)→Thread.start(__method.bind(args))Thread.is_active()→Thread.is_alive()
Check: Verwenden Signalverbindungen die Callable-Syntax?
Das alte Muster connect("signal_name", target, "method_name") ist veraltet. Godot 4 nutzt Callable-basierte Verbindungen:
# Alt (Godot 3)
button.connect("pressed", self, "_on_button_pressed")
# Aktuell (Godot 4)
button.pressed.connect(_on_button_pressed)Die Callable-Form ermöglicht Validierung zur Compile-Zeit. String-basierte Verbindungen brechen zur Laufzeit stillschweigend, wenn Sie die Methode umbenennen. (Signal-Docs)
Check: Sind Konstanten und Signalnamen aktuell?
Farbkonstanten haben ihr Format geändert (z. B. Color.palegreen → Color.PALE_GREEN). Manche Signalnamen wurden umbenannt (z. B. CanvasItem.hide → hidden). Prüfen Sie die Umbenennungstabellen in den Migrationsdocs.
2. Lifecycle-Callbacks
Läuft der Code im richtigen Callback?
Das ist die gefährlichste Kategorie, weil Code im falschen Callback trotzdem kompiliert, läuft und funktionierend wirkt. Er versagt erst unter realen Bedingungen: unterschiedliche Framerates, Physik-Edge-Cases oder abweichende Hardware. Godots Notification-Docs legen explizit fest, welcher Callback welchem Zweck dient.
Check: Liegt die Physikbewegung in _physics_process()?
_process() läuft bei jedem gerenderten Frame und ist framerate-abhängig. _physics_process() läuft mit einer festen Rate (standardmäßig 60 Mal pro Sekunde). Jeder Code, der move_and_slide(), move_and_collide() aufruft oder die Velocity eines Physikkörpers direkt manipuliert, gehört in _physics_process(). (Physik-Einführung)
Check: Wird Input am richtigen Ort verarbeitet?
Für diskrete Ereignisse (Tastendruck, Button-Klick) bevorzugen Sie _input() oder _unhandled_input(). Für kontinuierlichen Zustand (wird die Taste gedrückt gehalten) ist _process() oder _physics_process() mit Input.is_action_pressed() angemessen. Input bei jedem Frame in _process() abzufragen, obwohl es nur für Physikbewegung gebraucht wird, ist ein häufiges KI-generiertes Muster.
Check: Erledigt _ready() nur Setup, keine laufende Arbeit?
_ready() läuft einmal, wenn der Node dem Baum beitritt. Kinder durchlaufen _ready() vor den Eltern. Wenn die Initialisierung von einem Geschwister- oder Eltern-Node abhängt, der bereit sein muss, erwägen Sie await owner.ready oder das Verzögern des Setup-Aufrufs.
3. Signal-Hygiene
Halten Signale den Code entkoppelt?
Godots Signalsystem lässt Objekte auf Ereignisse reagieren, ohne sich direkt gegenseitig zu referenzieren. Die praktische Regel lautet „nach unten aufrufen, nach oben signalisieren“: Eltern-Nodes können Methoden auf Kindern direkt aufrufen, aber Kinder sollten nach oben über Signale kommunizieren. KI-generierter Code verstößt häufig dagegen, indem Kinder in Eltern oder Geschwister hineingreifen.
Check: Werden Signale statt direkter Eltern-Referenzen verwendet?
Wenn ein Kind-Node seine Eltern über ein Ereignis informieren muss, sollte es ein Signal emittieren. Die Eltern verbinden sich mit diesem Signal. Das Kind sollte nicht get_parent().some_method() aufrufen.
Check: Sind Signalverbindungen am richtigen Ort?
Der Node, den das Ereignis interessiert, sollte die Verbindung besitzen. Typischerweise verbinden sich Eltern-Nodes in _ready() mit den Signalen ihrer Kinder. Vermeiden Sie es, Signale in tief verschachtelten oder entfernten Teilen des Baums zu verbinden.
Check: Werden Signale bei Bedarf getrennt?
Wenn Nodes dynamisch hinzugefügt und entfernt werden, können verbleibende Signalverbindungen Fehler oder unerwartetes Verhalten verursachen. Prüfen Sie, ob disconnect() oder queue_free()-Aufräumarbeiten nötig sind.
4. Szenenbaum-Architektur
Setzt der Code eine feste Baumstruktur voraus?
Godot ist auf komposierbaren Szenen aufgebaut, die überall instanziiert werden können. Hartcodierte Pfade und Eltern-Referenzen brechen diese Komposierbarkeit. Die Docs zur Szenenorganisation besagen, dass wiederverwendbare Sub-Szenen funktionieren sollten, ohne Details über ihre Umgebung zu benötigen.
Check: Navigiert das Skript mit .. nach oben?
get_node(".."), get_parent() und Pfade wie ../../Player sind brüchig. Sie brechen, wenn die Szene neu geparentet, in einem anderen Kontext wiederverwendet oder umstrukturiert wird. Die Docs zu Nodes und Szeneninstanzen sagen, dass die Vermeidung von .. Best Practice ist.
Check: Sollte hier statt eines hartcodierten Pfads eine @export-Referenz stehen?
@export var target: Node erlaubt es, Referenzen im Editor zu verdrahten. Das ist robuster als get_node("../Player"), weil es Baumumstrukturierungen übersteht und Abhängigkeiten explizit macht.
Check: Sollten hier Gruppen statt direkter Referenzen verwendet werden?
Gruppen erlauben es, Nodes zu markieren und auf sie zuzugreifen, ohne ihren Pfad zu kennen. get_tree().get_nodes_in_group("enemies") ist widerstandsfähiger als das Iterieren über Kinder nach Namen.
Check: Sind die Eltern-Kind-Beziehungen sinnvoll? Die Docs sagen, Eltern-Kind-Beziehungen sollten echte Enthaltensein-Beziehungen abbilden: Wenn das Entfernen der Eltern nicht auch das Kind entfernen sollte, gehört das Kind vielleicht woanders in den Baum. KI verschachtelt Nodes oft aus Bequemlichkeit statt aus semantischer Korrektheit.
5. Typsicherheit und Warnungen
Nutzt das Projekt Godots eingebaute Sicherheitswerkzeuge?
GDScript unterstützt statische Typisierung und hat ein eingebautes Warnsystem. Beides ist optional, reduziert aber deutlich Laufzeit-Überraschungen. Die Docs sagen, dass statische Typen helfen, Fehler ohne Ausführen des Codes zu erkennen, und die Editor-Autovervollständigung verbessern.
Check: Sind Funktionsparameter und Rückgabetypen annotiert?
# Ungetypt (funktioniert, aber riskant)
func take_damage(amount):
health -= amount
# Getypt (fängt Fehler beim Parsen ab)
func take_damage(amount: int) -> void:
health -= amountBest Practice ist alles oder nichts. Die Docs warnen, dass das Mischen von getyptem und ungetyptem Code im selben Projekt Verwirrung stiftet.
Check: Werden Warnungen ernst genommen? Godots Warnsystem erkennt unbenutzte Variablen, unerreichbaren Code und Muster, die zu Laufzeitfehlern führen können. Warnungen können in den Projekteinstellungen zu Fehlern hochgestuft werden. Wenn Ihr Projekt alle Warnungen ignoriert, verstecken sich Bugs.
Check: Sind @warning_ignore-Annotationen gerechtfertigt?
Godot unterstützt @warning_ignore("unused_variable") und ähnliche Annotationen. Jede sollte bewusst gesetzt sein, nicht als Weg, Lärm zu unterdrücken. Fragen Sie beim Review: Versteckt dieses Ignore ein echtes Problem, oder ist es eine bewusste Ausnahme?
6. Ressourcenverwaltung
Lädt, erstellt und gibt der Code Dinge sicher frei?
Godots Ressourcensystem ist mächtig, hat aber Muster, die KI häufig falsch macht — besonders rund um Laden, Instanziierung und Cleanup.
Check: Ist load() vs. preload() bewusst gewählt?
preload() lädt zur Compile-Zeit und benötigt einen konstanten String-Pfad. load() läuft an der Zeile, an der es aufgerufen wird. Verwenden Sie preload() für Ressourcen, die Sie immer brauchen. Verwenden Sie load() für Ressourcen, die bedingt oder dynamisch geladen werden. KI neigt dazu, load() überall zu verwenden, weil es flexibler ist, aber das erzeugt unnötiges Laden zur Laufzeit.
Check: Werden Packed Scenes korrekt instanziiert?
In Godot 4 sind gespeicherte Szenen PackedScene-Ressourcen. Sie rufen instantiate() auf (nicht instance(), das der Godot-3-Name ist), um den Node-Baum zu erstellen. Prüfen Sie, dass instanziierte Szenen mit add_child() dem Baum hinzugefügt werden.
Check: Werden Nodes sicher freigegeben?
Verwenden Sie queue_free(), sofern Sie keinen bestimmten Grund haben, es nicht zu tun. free() zerstört den Node sofort, und alle Referenzen darauf werden augenblicklich null. queue_free() wartet bis zum Ende des aktuellen Frames, was sicherer ist. Die Docs empfehlen queue_free() als Standard.
Check: Werden Autoloads sparsam eingesetzt?
Autoloads sind global zugänglich, aber immer noch Nodes im Szenenbaum. Sie dürfen zur Laufzeit niemals mit free() oder queue_free() entfernt werden, sonst stürzt die Engine ab. KI-generierter Code behandelt Autoloads manchmal wie entsorgbare Manager. Prüfen Sie im Review, ob globaler Zustand wirklich global sein muss oder auch eine Ressource oder Gruppe sein könnte.
Was diese Checkliste nicht abdeckt
Diese Checkliste behandelt Code-Review: Korrektheit, Architektur und Muster. Sie ersetzt nicht:
- Linter und Formatter. Tools wie
gdscript-toolkitund Godots eingebaute Warnungen fangen Syntax, Formatierung, unbenutzte Variablen und manche Typprobleme ab. Nutzen Sie sie. Sie ergänzen sich. - Playtesting. Code-Review erkennt strukturelle Probleme. Es erkennt nicht „das fühlt sich nicht richtig an“ oder „der Sprung ist zu schwammig“. Das ist Testing.
- Architektur-Design. Diese Checkliste fragt „ist die Architektur solide?“ Sie sagt Ihnen nicht, welche Architektur Sie verwenden sollen. Dafür lesen Sie Godots Abschnitt Best Practices.
Die Checkliste automatisieren
Sie können diese Liste bei jedem PR manuell durchgehen. Oder Sie automatisieren es.
Surmado Code Review für Godot prüft jeden Push in einen GitHub-Pull-Request gegen die offizielle Godot-4.6-Dokumentation, Ihren Repo-Kontext und Ihre STANDARDS.MD. Es erkennt Versionsfehler, falsche Lifecycle-Nutzung, veraltete Muster, brüchige Szenenbaum-Pfade und was auch immer Sie an eigenen Regeln definieren.
Kostenlos für 10 PRs pro Monat. 15 $/Monat für 100. Keine Preise pro Sitzplatz.
Die Checkliste sagt Ihnen, was zu prüfen ist. Surmado Code Review sagt Ihnen, wie Sie es bei jedem PR prüfen, ohne selbst über Diffs zu starren.
Surmado Code Review für Godot installieren (Kostenlos) →
Unsicher bei einer bestimmten Godot-API oder einem Muster? Fragen Sie GDScout gegen die offizielle 4.6-Dokumentation. Kostenlos, mit Quellenangaben.
Fragen und Antworten
Gibt es eine GDScript-Code-Review-Checkliste? Ja. Die GDScript-Code-Review-Checkliste deckt sechs Kategorien ab: Versionskorrektheit (Godot-3- vs. Godot-4-Muster), Lifecycle-Callbacks (_process vs. _physics_process), Signal-Hygiene, Szenenbaum-Architektur, Typsicherheit und Warnungen sowie Ressourcenverwaltung. Jeder Check basiert auf der offiziellen Godot-4.6-Dokumentation.
Was sollte ich in einem Godot-Code-Review prüfen? Ein Godot-Code-Review sollte Versionskorrektheit prüfen (keine Godot-3-Muster in einem Godot-4-Projekt), korrekte Nutzung der Lifecycle-Callbacks, Callable-basierte Signalverbindungen, komposierbare Szenenbaum-Architektur ohne brüchige Eltern-Pfade, Einhaltung von statischer Typisierung und Warnungen sowie sicheres Laden von Ressourcen und Node-Cleanup. Die GDScript-Code-Review-Checkliste liefert konkrete Checks für jede Kategorie mit Links zur offiziellen Dokumentation.
Hat Godot ein Code-Review-Tool? Godots eingebaute Tools umfassen ein GDScript-Warnsystem und Unterstützung für statische Typisierung, die Syntax- und Typfehler abfangen. Für Code-Review auf PR-Ebene prüft Surmado Code Review für Godot GitHub-Pull-Requests gegen die offizielle Godot-4.6-Dokumentation und die STANDARDS.MD eines Teams. Es erkennt Versionsfehler, falsche Lifecycle-Nutzung, veraltete Muster und Architekturprobleme, die Linter nicht abdecken. Kostenlos für 10 PRs pro Monat.
Was sind die häufigsten Fehler in KI-generiertem Godot-Code? Die häufigsten Fehler sind die Nutzung umbenannter Godot-3-Node-Typen und Methodensignaturen, das Platzieren von Physikbewegung in _process() statt _physics_process(), die Verwendung veralteter, string-basierter Signalverbindungen, hartcodierte, brüchige Eltern- und Geschwister-Node-Pfade sowie die Nutzung von load() statt preload() für Ressourcen, die zur Compile-Zeit geladen werden sollten. Diese Muster bestehen Linting und kompilieren fehlerfrei, verursachen aber Laufzeitfehler oder inkonsistentes Verhalten.
Wie unterscheidet sich eine Code-Review-Checkliste von einem GDScript-Linter? Ein GDScript-Linter erkennt Syntaxfehler, Formatierungsprobleme, unbenutzte Variablen und manche Typprobleme. Eine Code-Review-Checkliste bewertet Fragen auf höherer Ebene: Ist dies die korrekte API der Engine-Version, liegt Bewegungscode im richtigen Callback, sind Signalverbindungen modern, ist die Szenenbaum-Architektur komposierbar, und folgt der Code projektspezifischen Standards. Linter und Code-Review ergänzen sich.
Was ist STANDARDS.MD? STANDARDS.MD ist ein Markdown-Dokument, das die Coding-Standards definiert, die ein Team beim Code-Review durchsetzt. In Surmado Code Review entsteht STANDARDS.MD durch ein Gespräch mit Scout, Surmados KI-Agent, statt durch das Bearbeiten einer Konfigurationsdatei. Das Dokument kann Godot-spezifische Regeln enthalten, etwa „immer _physics_process für CharacterBody-Bewegung verwenden“ oder „keine Eltern-Pfad-Navigation mit get_node(‘..’)“.