Stewart sigue un conjunto de convenciones de código para mantener el proyecto consistente y legible para todos los contribuidores. El lenguaje principal es GDScript, y se acepta C# como alternativa opcional. Estas guías cubren desde la nomenclatura de variables y clases hasta el formato de los mensajes de commit.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Stewart-DevTeam-Team/stewart_prealpha/llms.txt
Use this file to discover all available pages before exploring further.
Convenciones de GDScript
Nomenclatura
El proyecto usa tres estilos de nomenclatura según el tipo de símbolo:| Estilo | Uso | Ejemplos |
|---|---|---|
snake_case | Variables, funciones, archivos | player_name, play_anim(), flags_manager.gd |
PascalCase | Nombres de clase | Character, StateMachine, BaseState, AutoloadResource |
UPPER_SNAKE_CASE | Constantes | PATH_MAX_LENGTH, CHARA_DISTANCE, EPSILON |
Comentarios y documentación
Se usan## para doc-comments en el formato de documentación de Godot, y # para comentarios de línea regulares.
Clases abstractas
Las clases que no deben instanciarse directamente usan la anotación@abstract:
Propiedades del inspector
Se usa@export para exponer propiedades al inspector de Godot, y @export_group para agruparlas:
Referencias a nodos
Las referencias a nodos del árbol de escena se declaran con@onready:
StringNames
Los literales de tipoStringName usan el prefijo & para evitar conversiones innecesarias en tiempo de ejecución:
Señales
Las señales se declaran con la palabra clavesignal:
Regiones de código
Para organizar archivos largos se usan#region y #endregion:
Estructura general de un archivo
Un archivo GDScript típico del proyecto sigue este orden:Convención bilingüe
El proyecto usa dos idiomas con roles distintos:| Idioma | Uso |
|---|---|
| Inglés | Nombres de variables, funciones, señales, constantes y clases |
| Español | Comentarios, doc-strings y mensajes de error |
Convenciones de commits
El proyecto sigue la especificación de Conventional Commits. El formato es:Tipos de commit
| Tipo | Uso |
|---|---|
feat | Nueva funcionalidad |
fix | Corrección de error |
docs | Cambios en documentación |
chore | Mantenimiento (dependencias, configuración, etc.) |
refactor | Refactorización sin cambio de comportamiento |
art | Cambios en assets de arte |
Ejemplos
El ámbito (
scope) es opcional pero recomendado cuando el cambio afecta un sistema específico. Usar ámbitos consistentes facilita leer el historial del proyecto con git log.