Bonjour à tous,
En travaillant sur mon projet, je suis tombé sur un comportement qui mérite d’être signalé, parce qu’il a des conséquences concrètes.
Le constat
Quand on configure une condition ou une action qui a plusieurs modes/types de paramètres possibles (par exemple une comparaison de variable qui peut être Nombre / Texte / Booléen, ou une action de son qui peut être configurée de plusieurs façons différentes), et qu’on change de mode après coup, les anciens paramètres ne sont pas nettoyés dans le JSON du projet. Ils restent stockés dans les emplacements de paramètres devenus inutiles.
Exemple concret avec une condition “Comparer la valeur d’une variable booléenne” :
{
"type": { "value": "BooleanObjectVariable" },
"parameters": ["MonObjet", "MaVariable", ">=", "MonObjet.UneAutreVariable"]
}
au lieu de
{
"type": { "value": "BooleanObjectVariable" },
"parameters": ["MonObjet", "MaVariable", "True", ""]
}
Dans l’éditeur, tout s’affiche normalement et la condition fonctionne (visiblement tout ce qui n’est pas littéralement "False" est traité comme vrai) donc ce n’est pas un bug qui casse le jeu. Mais le JSON lui-même contient un résidu qui n’a plus aucun sens fonctionnel.
J’ai observé le même genre de phénomène avec la gestion du son : il existe plusieurs façons de configurer une action de lecture de son (avec ou sans canal, par nom de fichier, etc.), et quand on passe d’une configuration à une autre, les paramètres de l’ancienne configuration restent dans le JSON au lieu d’être nettoyés.
Pourquoi ça pose problème
-
Poids du fichier projet : sur un gros projet, ça ajoute une quantité non négligeable de données mortes qui n’ont plus aucune fonction, juste du bruit dans le JSON.
-
Diffs Git illisibles : pour ceux qui versionnent leur projet, ces résidus peuvent apparaître/disparaître dans les diffs sans lien avec un vrai changement de comportement, ce qui complique la revue de code.
-
Analyse automatisée / IA faussée : j’ai utilisé un outil d’IA pour auditer mon projet directement depuis le JSON exporté, et plusieurs de ces résidus ont été remontés comme des bugs potentiels (conditions “cassées”) alors qu’ils sont en réalité inoffensifs. Sans accès à l’éditeur pour vérifier visuellement, impossible de distinguer un vrai résidu inoffensif d’une vraie erreur de configuration, les deux ont exactement la même signature dans le JSON.
-
Dette technique silencieuse : si un jour le comportement “tout ce qui n’est pas
Falseest vrai” change (nouvelle version, refonte du système de variables…), ces résidus pourraient se transformer en vrais bugs silencieux, sans qu’on ait de moyen simple de les repérer à l’avance.
Ce que je proposerais
- Un outil/bouton de “nettoyage de projet” (lint) qui détecte et purge ce genre de résidus dans un projet existant, pour repartir sur un JSON propre.
Ce serait bien d’avoir au moins un moyen de nettoyer un projet existant. Merci d’avance pour vos retours !
