Godot n’a pas de checklist de revue de code standard. Le moteur dispose d’un guide de style, d’un système d’avertissements, et de lignes directrices de revue de PR pour les contributeurs du moteur. Mais si vous développez un jeu avec une petite équipe ou en solo et que vous poussez du code sur GitHub, il n’existe pas de ressource canonique du type « vérifiez ces points avant de merger ».
C’est cette ressource.
Chaque vérification ci-dessous s’appuie sur la documentation officielle de Godot 4.6. Lorsqu’une vérification renvoie à une page précise de la documentation, elle est liée. La checklist est organisée en six catégories qui couvrent les problèmes les plus courants observés dans les pull requests Godot, en particulier dans les projets utilisant le développement assisté par IA, où les schémas de mauvaise version et le code plausible mais cassé apparaissent régulièrement.
Utilisez-la avant de merger. Imprimez-la. Mettez-la dans le CONTRIBUTING.md de votre dépôt. Ou installez Surmado Code Review sur le dépôt et laissez Scout vérifier automatiquement le diff.
1. Exactitude de la version
Ce code est-il réellement écrit pour Godot 4 ?
C’est la catégorie prioritaire pour tout projet utilisant l’assistance IA. Les LLM sont entraînés sur des années de tutoriels Godot 3, de réponses de forums et de documentation. Ils produiront avec assurance du code Godot 3 dans un projet Godot 4. Le guide de migration officiel liste des centaines de renommages et de changements incompatibles. Le convertisseur de projet intégré en corrige beaucoup, mais la documentation de Godot elle-même prévient que les scripts migrés contiendront probablement encore des erreurs et qu’une grande partie de la migration reste manuelle.
Même après migration, l’IA peut réintroduire d’anciens schémas dans de nouveaux fichiers. Cette catégorie capte à la fois le code hérité et le code fraîchement généré par IA qui a appris depuis la mauvaise version.
Vérification : les noms de classes de nœuds sont-ils tous à jour ? Recherchez les classes renommées. Les plus courantes :
KinematicBody2D→CharacterBody2DKinematicBody→CharacterBody3DPosition2D→Marker2D,Position3D→Marker3DSpatial→Node3DSprite→Sprite2D
La liste complète des renommages se trouve dans la documentation de migration.
Vérification : les signatures de méthodes sont-elles à jour ? Plusieurs méthodes couramment utilisées ont changé de signature ou ont été renommées :
move_and_slide()ne prend plus d’arguments. Elle lit la propriété intégréevelocitydu nœud. (Documentation CharacterBody2D)instance()→instantiate()set_shader_param()→set_shader_parameter()map_to_world()→map_to_local()(GridMap et TileMap)change_scene()→change_scene_to_file()Thread.start(self, "__method", args)→Thread.start(__method.bind(args))Thread.is_active()→Thread.is_alive()
Vérification : les connexions de signaux utilisent-elles la syntaxe callable ?
L’ancien schéma connect("signal_name", target, "method_name") est déprécié. Godot 4 utilise des connexions basées sur des callables :
# Ancien (Godot 3)
button.connect("pressed", self, "_on_button_pressed")
# Actuel (Godot 4)
button.pressed.connect(_on_button_pressed)La forme callable offre une validation à la compilation. Les connexions basées sur des chaînes se cassent silencieusement à l’exécution si vous renommez la méthode. (Documentation Signal)
Vérification : les constantes et les noms de signaux sont-ils à jour ?
Le format des constantes de couleur a changé (par exemple, Color.palegreen → Color.PALE_GREEN). Certains noms de signaux ont été renommés (par exemple, CanvasItem.hide → hidden). Consultez les tableaux de renommage de la documentation de migration.
2. Callbacks du cycle de vie
Le code s’exécute-t-il dans le bon callback ?
C’est la catégorie la plus dangereuse, car le code placé dans le mauvais callback compile, s’exécute et semble fonctionner. Il échoue dans des conditions réelles : fréquences d’images différentes, cas limites de physique, ou variations matérielles. La documentation des notifications de Godot indique explicitement quel callback sert quel objectif.
Vérification : le mouvement physique est-il dans _physics_process() ?
_process() s’exécute à chaque image rendue et dépend du framerate. _physics_process() s’exécute à une fréquence fixe (60 fois par seconde par défaut). Tout code qui appelle move_and_slide(), move_and_collide(), ou qui manipule directement la vélocité d’un corps physique appartient à _physics_process(). (Introduction à la physique)
Vérification : l’entrée utilisateur est-elle gérée au bon endroit ?
Pour les événements discrets (appui de touche, clic de bouton), privilégiez _input() ou _unhandled_input(). Pour un état continu (la touche est-elle maintenue), _process() ou _physics_process() avec Input.is_action_pressed() est approprié. Interroger l’entrée à chaque image dans _process() alors qu’elle n’est nécessaire que pour le mouvement physique est un schéma courant du code généré par IA.
Vérification : _ready() fait-il de la configuration, pas du travail continu ?
_ready() s’exécute une fois, quand le nœud entre dans l’arbre. Les enfants exécutent _ready() avant les parents. Si l’initialisation dépend d’un nœud frère ou parent déjà prêt, envisagez d’utiliser await owner.ready ou de différer l’appel de configuration.
3. Hygiène des signaux
Les signaux maintiennent-ils le code découplé ?
Le système de signaux de Godot permet aux objets de réagir à des événements sans se référencer directement. La règle pratique est « appeler vers le bas, signaler vers le haut » : les nœuds parents peuvent appeler directement des méthodes sur leurs enfants, mais les enfants doivent communiquer vers le haut via des signaux. Le code généré par IA viole fréquemment cette règle en faisant en sorte que des enfants accèdent directement à des parents ou des frères.
Vérification : des signaux sont-ils utilisés à la place de références directes au parent ?
Si un nœud enfant doit informer son parent qu’un événement s’est produit, il doit émettre un signal. Le parent se connecte à ce signal. L’enfant ne doit pas appeler get_parent().some_method().
Vérification : les connexions de signaux sont-elles au bon endroit ?
Le nœud qui se soucie de l’événement doit posséder la connexion. Typiquement, les nœuds parents se connectent aux signaux de leurs enfants dans _ready(). Évitez de connecter des signaux dans des parties profondément imbriquées ou éloignées de l’arbre.
Vérification : les signaux sont-ils déconnectés quand nécessaire ?
Si des nœuds sont ajoutés et supprimés dynamiquement, des connexions de signaux persistantes peuvent provoquer des erreurs ou un comportement inattendu. Vérifiez si un nettoyage via disconnect() ou queue_free() est nécessaire.
4. Architecture de l’arbre de scène
Le code suppose-t-il une structure d’arbre fixe ?
Godot est conçu autour de scènes composables qui peuvent être instanciées n’importe où. Les chemins codés en dur et les références au parent brisent cette composabilité. La documentation d’organisation des scènes indique que les sous-scènes réutilisables devraient fonctionner sans avoir besoin de détails sur leur environnement.
Vérification : le script navigue-t-il vers le haut avec .. ?
get_node(".."), get_parent(), et des chemins comme ../../Player sont fragiles. Ils se cassent si la scène est réattachée à un autre parent, réutilisée dans un contexte différent, ou restructurée. La documentation sur les nœuds et instances de scène indique qu’éviter .. est une bonne pratique.
Vérification : cela devrait-il être une référence @export plutôt qu’un chemin codé en dur ?
@export var target: Node permet de câbler des références depuis l’éditeur. C’est plus robuste que get_node("../Player") car cela survit à la restructuration de l’arbre et rend les dépendances explicites.
Vérification : cela devrait-il utiliser des groupes plutôt que des références directes ?
Les groupes permettent de taguer des nœuds et d’y accéder sans connaître leur chemin. get_tree().get_nodes_in_group("enemies") est plus résilient que d’itérer sur les enfants par nom.
Vérification : les relations parent-enfant ont-elles du sens ? La documentation indique que les relations parent-enfant devraient représenter une véritable relation de contenance : si supprimer le parent ne devrait pas supprimer l’enfant, l’enfant appartient peut-être ailleurs dans l’arbre. L’IA imbrique souvent des nœuds par commodité plutôt que par correction sémantique.
5. Sécurité des types et avertissements
Le projet utilise-t-il les outils de sécurité intégrés de Godot ?
GDScript prend en charge le typage statique et dispose d’un système d’avertissements intégré. Les deux sont optionnels mais réduisent nettement les surprises à l’exécution. La documentation indique que les types statiques aident à détecter les erreurs sans exécuter le code et améliorent l’autocomplétion de l’éditeur.
Vérification : les paramètres de fonction et les types de retour sont-ils annotés ?
# Non typé (fonctionne mais risqué)
func take_damage(amount):
health -= amount
# Typé (capture les erreurs à l'analyse)
func take_damage(amount: int) -> void:
health -= amountLa bonne pratique est tout ou rien. La documentation prévient que mélanger du code typé et non typé dans le même projet crée de la confusion.
Vérification : les avertissements sont-ils pris au sérieux ? Le système d’avertissements de Godot détecte les variables inutilisées, le code inatteignable, et les schémas susceptibles de provoquer des erreurs à l’exécution. Les avertissements peuvent être élevés au rang d’erreurs dans les paramètres du projet. Si votre projet ignore tous les avertissements, des bugs se cachent.
Vérification : les annotations @warning_ignore sont-elles justifiées ?
Godot prend en charge @warning_ignore("unused_variable") et des annotations similaires. Chacune devrait être intentionnelle, pas un moyen de faire taire du bruit. Pendant la revue, demandez-vous : cette suppression cache-t-elle un vrai problème, ou est-ce une exception délibérée ?
6. Gestion des ressources
Le code charge-t-il, crée-t-il et libère-t-il les objets en toute sécurité ?
Le système de ressources de Godot est puissant mais comporte des schémas que l’IA se trompe fréquemment, en particulier autour du chargement, de l’instanciation et du nettoyage.
Vérification : le choix entre load() et preload() est-il intentionnel ?
preload() charge à la compilation et requiert un chemin de chaîne constant. load() s’exécute à la ligne où il est appelé. Utilisez preload() pour les ressources dont vous avez toujours besoin. Utilisez load() pour les ressources chargées conditionnellement ou dynamiquement. L’IA a tendance à utiliser load() partout parce que c’est plus flexible, mais cela crée un chargement à l’exécution inutile.
Vérification : les scènes empaquetées sont-elles instanciées correctement ?
Dans Godot 4, les scènes enregistrées sont des ressources PackedScene. Vous appelez instantiate() (pas instance(), qui est le nom Godot 3) pour créer l’arbre de nœuds. Vérifiez que les scènes instanciées sont ajoutées à l’arbre avec add_child().
Vérification : les nœuds sont-ils libérés en toute sécurité ?
Utilisez queue_free() sauf raison précise de ne pas le faire. free() détruit immédiatement le nœud, et toute référence à celui-ci devient nulle instantanément. queue_free() attend la fin de l’image courante, ce qui est plus sûr. La documentation recommande queue_free() par défaut.
Vérification : les autoloads sont-ils utilisés avec parcimonie ?
Les autoloads sont accessibles globalement, mais restent des nœuds dans l’arbre de scène. Ils ne doivent jamais être supprimés avec free() ou queue_free() à l’exécution, sous peine de faire planter le moteur. Le code généré par IA traite parfois les autoloads comme des gestionnaires jetables. Vérifiez si l’état global a vraiment besoin d’être global ou pourrait être une ressource ou un groupe à la place.
Ce que cette checklist ne couvre pas
Cette checklist couvre la revue de code : correction, architecture et schémas. Elle ne remplace pas :
- Les linters et formateurs. Des outils comme
gdscript-toolkitet les avertissements intégrés de Godot détectent la syntaxe, le formatage, les variables inutilisées et certains problèmes de type. Utilisez-les. Ils sont complémentaires. - Les playtests. La revue de code capte les problèmes structurels. Elle ne capte pas « ça ne semble pas naturel » ou « le saut est trop flottant ». C’est le rôle des tests.
- La conception d’architecture. Cette checklist demande « l’architecture est-elle solide ? ». Elle ne vous dit pas quelle architecture utiliser. Pour cela, lisez la section bonnes pratiques de Godot.
Automatiser la checklist
Vous pouvez parcourir cette liste manuellement à chaque PR. Ou vous pouvez l’automatiser.
Surmado Code Review pour Godot vérifie chaque push sur une pull request GitHub par rapport à la documentation officielle de Godot 4.6, au contexte de votre dépôt et à votre STANDARDS.MD. Il détecte les erreurs de version, les mauvais usages du cycle de vie, les schémas dépréciés, les chemins fragiles dans l’arbre de scène, et toutes les règles personnalisées que vous définissez.
Gratuit pour 10 PR par mois. 15 $/mois pour 100. Pas de tarification par siège.
La checklist indique quoi vérifier. Surmado Code Review indique comment le vérifier sur chaque PR sans avoir à fixer les diffs.
Installer Surmado Code Review pour Godot (gratuit) →
Pas sûr d’une API ou d’un schéma Godot précis ? Demandez à GDScout en vous appuyant sur la documentation officielle 4.6. Gratuit, avec citations.
Questions et réponses
Existe-t-il une checklist de revue de code GDScript ? Oui. La checklist de revue de code GDScript couvre six catégories : exactitude de la version (schémas Godot 3 vs 4), callbacks du cycle de vie (_process vs _physics_process), hygiène des signaux, architecture de l’arbre de scène, sécurité des types et avertissements, et gestion des ressources. Chaque vérification s’appuie sur la documentation officielle de Godot 4.6.
Que dois-je vérifier lors d’une revue de code Godot ? Une revue de code Godot devrait vérifier l’exactitude de la version (pas de schémas Godot 3 dans un projet Godot 4), l’utilisation correcte des callbacks du cycle de vie, des connexions de signaux basées sur des callables, une architecture d’arbre de scène composable sans chemins parents fragiles, la conformité au typage statique et aux avertissements, et le chargement et le nettoyage sûrs des ressources. La checklist de revue de code GDScript fournit des vérifications précises pour chaque catégorie avec des liens vers la documentation officielle.
Godot dispose-t-il d’un outil de revue de code ? Les outils intégrés de Godot incluent un système d’avertissements GDScript et un support de typage statique, qui détectent les erreurs de syntaxe et de type. Pour la revue de code au niveau des PR, Surmado Code Review pour Godot vérifie les pull requests GitHub par rapport à la documentation officielle de Godot 4.6 et au STANDARDS.MD d’une équipe. Il détecte les erreurs de version, les mauvais usages du cycle de vie, les schémas dépréciés, et les problèmes d’architecture que les linters ne couvrent pas. Gratuit pour 10 PR par mois.
Quelles sont les erreurs les plus courantes dans le code Godot généré par IA ? Les erreurs les plus courantes sont l’utilisation de types de nœuds et de signatures de méthodes Godot 3 renommés, le placement du mouvement physique dans _process() au lieu de _physics_process(), l’utilisation de connexions de signaux basées sur des chaînes dépréciées, le codage en dur de chemins de nœuds parents et frères fragiles, et l’utilisation de load() au lieu de preload() pour des ressources compilées. Ces schémas passent le linting et compilent sans erreur mais provoquent des échecs à l’exécution ou un comportement incohérent.
En quoi une checklist de revue de code diffère-t-elle d’un linter GDScript ? Un linter GDScript détecte les erreurs de syntaxe, les problèmes de formatage, les variables inutilisées et certains problèmes de type. Une checklist de revue de code évalue des préoccupations de plus haut niveau : est-ce la bonne API de version du moteur, le code de mouvement est-il dans le bon callback, les connexions de signaux sont-elles modernes, l’architecture de l’arbre de scène est-elle composable, et le code suit-il les standards propres au projet. Les linters et la revue de code sont complémentaires.
Qu’est-ce que STANDARDS.MD ? STANDARDS.MD est un document Markdown qui définit les standards de code qu’une équipe applique lors de la revue de code. Dans Surmado Code Review, STANDARDS.MD est créé via une conversation avec Scout, l’agent IA de Surmado, plutôt qu’en modifiant un fichier de configuration. Le document peut inclure des règles spécifiques à Godot comme « toujours utiliser _physics_process pour le mouvement CharacterBody » ou « pas de navigation par chemin parent avec get_node(‘..’) ».