###### tags: `Développement`
# Guide de développement

Cette page sert à référencer les "règles" ou "bonnes pratiques" à appliquer dans le projet. Cela va des règles de nommage aux bonnes pratiques de programmation à adopter etc.

A lire aussi : [Guide du Workflow Git](/@alpagames/wiki/eyAE8odSSOmAAkzVYNPp6g)

## Formalités

### Guide de style
[Lire le guide de style de GDQuest](https://www.gdquest.com/docs/guidelines/best-practices/godot-gdscript/) (en anglais)

**En bref :**
| Type | Casse |
|-|-|
| Variables, fonctions, signaux | smol_snek |
|Classes, types d'enum, variables de référence à une classe¹ | PascalCase |
|Valeurs d'enum, constantes| BIG_SNEK |

1 : Un exemple de variable de réf à une classe serait `var Bullet = load("res://Bullet.tscn")`

### Règles de nommage

Les règles de nommage du **guide de style GDScript** sont à appliquer.
**Utilisez les [docstrings](https://github.com/GDQuest/gdscript-docs-maker#writing-your-code-reference) pour documenter votre code**, une documentation sera générée à partir de ça.

**Noms de fichiers** : Tout ce qui est dans `assets` est en `snake_case`, tout ce qui est dans `src` en `PascalCase`.

**Noms de branche :** En ```kebab-case```. (Plus d'infos dans le [workflow Git]).

**Le reste :** Tous les commentaires, docs, messages de commits etc, sont en français. Soyez le plus clair possible dedans, c'est un outil de communication.

### Structure des fichiers du projet

[Pour modifier](https://tree.nathanfriend.io/)
Voici la structure de fichiers à adopter pour le projet.

**src :** Contient le code du projet
**assets :** Contient les fichiers d'asset publics. Les artistes n'auront à toucher qu'à ce dossier.

Les fichiers doivent être rangés par thèmes, par systèmes, bref que ça soit compréhensible. Il est possible d'ajouter autant de dossiers/sous-dossiers que nécessaire.

.
├── assets/        # Fichiers d'assets publics. Les artistes déposent ici.
│   ├── audio/     # Les sous-dossiers ont du sens
│   ├── fonts/
│   ├── sprites/
│   │   ├── player/un_sprite.png    # Fichiers en snake_case
│   │   └── enemy/
│   └── ui/
└── src/           # Contient le code à proprement parlé
    ├── Autoloads/ # Fichiers autoloads (singletons)
    ├── Levels/    # Un exemple de sous-dossier 
    │   ├── BaseLevel.tscn
    │   └── BaseLevel.gd
    └── Main/      # Contient la base du jeu, un minimum de fichiers
        ├── Game.tscn
        └── Game.gd

## Principes de dev

Des principes de développement à appliquer pour vous aider à écrire du code robuste.

### 1. KISS : Keep It Simple, Stupid

Faites les choses simplement. Si quelque chose devient trop compliqué, prenez du recul et demandez vous si vous ne pouvez pas le faire plus simplement.

### 2. Pensez modulaire

**Godot** est un moteur de jeu pensé pour la modularité. Logiquement, un **noeud** peut être sorti d'une scène et fonctionner sans problème. Utilisez un maximum les **signaux** pour échanger des infos entre les **noeuds**. Si vous devez passer des références, faites le **toujours** du haut vers le bas, ou à l'aide des signaux le cas échéant.

### 3. Le singleton est votre ami

Dans le jeu vidéo, le **patron de conception singleton** (singleton design pattern) est votre ami.
En gros : Vous avez un objet statique au dessus de tous les autres, qui gère des trucs. Ce qui vous permet d'utiliser ses fonctions sans avoir de référence, entre autres.

Dans Godot, le pattern singleton est possible à l'aide des [autoloads](https://docs.godotengine.org/fr/stable/getting_started/step_by_step/singletons_autoload.html)

### 4. Principe de simple responsabilité

Sûrement le plus important. Toutes vos classes doivent avoir **1 seule responsabilité**, c'est à dire, un seul type de tâche à faire.

Cela implique de **bien nommer ses classes**, pour savoir exactement ce qu'elles font. Pour les gros objets (comme le joueur, les ennemis etc.), séparer votre script en plusieur sous-scripts (scripts attachés aux noeuds enfants). Une scène `Player` pourrait avoir cette structure

Player (script PlayerController) # Gère les mouvements
    AnimationTree    # Gère les animations
    Inventory        # Gère l'inventaire du joueur
    BulletManager    # Gère les différents types de munition
    HitTimer         # Gère le cooldown quand le joueur est touché

Ne vous obligez pas à éclater vos classes pour le plaisir, faites le selon vos besoins.

Voici une liste non exhaustive de mots avec lesquels vous pouvez nommer vos classes. Si vous voyez qu'une de vos classes ressemble déjà à une classe dans le projet, essayez d'utiliser un nom similaire.

Manager, Handler, Controller, Coordinator, Builder, Writer, Reader, Container, Target, Converter...

Souvent les singletons sont nommés "Manager" (à utiliser avec modération, car peu explicite).

## Numéros de versions

Les numéros de versions seront automatiquement gerés par le script Gitlab. Voici le **versionnage sémantique**, le système que nous allons utiliser.

Un nom de version est de la forme `MAJEUR.MINEUR.HOTFIX`

**Majeur :** Un numéro de version majeur qui correspond à un passage d'une grande étape (passage de l'alpha à la beta, de la beta à la release, mise à jour majeures etc.)

**Mineur :** Ce numéro est incrémenté à chaque fois qu'une **fonctionnalité** est fusionnée dans la branche master. (Branches feat/\*)

**Hotfix :** Ce numéro est incrémenté pour le reste, les fix de bugs, les ajouts d'assets etc. (Branches hotfix/\* ou assets/\* etc.)

Le script utilise le nom de vos branches pour modifier le numéro de version, c'est pourquoi il faut [bien nommer vos branches](/@alpagames/wiki/eyAE8odSSOmAAkzVYNPp6g)