Galactic-Shrine C++ Coding Standard

Version: 1.0.0
Auteur / Author: ⋞Galactic-Shrine⋟
Portée / Scope: Projets C++ / Moteurs / Bibliothèques natives / Outils / Applications Desktop / Modules système / Intégrations Unreal-like ou propriétaires

1. Objectif

Ce standard définit la manière d’écrire le code C++ dans les projets Galactic-Shrine.

Il a pour objectifs :

• d’uniformiser le style C++ des bibliothèques et modules natifs ;
• de conserver une base robuste, lisible et industrialisable ;
• de limiter les erreurs de gestion mémoire, de contrat et d’interface ;
• d’aligner les conventions de nommage avec Galactic-Shrine.

2. Principes généraux

Le code C++ Galactic-Shrine doit être :

• clair ;
• sûr autant que possible ;
• cohérent ;
• orienté RAII ;
• attentif aux coûts réels.

Le code doit privilégier :

• des interfaces nettes ;
• des responsabilités courtes ;
• l’usage de types explicites ;
• des ressources gérées automatiquement ;
• la réduction des dépendances de compilation inutiles.

3. Décisions officielles Galactic-Shrine pour C++

Décisions officielles :

• classes, structs, enums, aliases de types : PascalCase ;
• méthodes : PascalCase ;
• paramètres : PascalCase ;
• propriétés ou accesseurs exposés : PascalCase ;
• variables locales : PascalCase ;
• champs privés : _PascalCase ;
• constantes nommées : PascalCase ;
• préférer enum class à enum lorsque pertinent ;
• préférer nullptr à NULL ;
• privilégier RAII et smart pointers quand la sémantique le justifie.

4. Convention de nommage

• fichiers .hpp / .h et .cpp alignés sur le type principal ;
• classes / structs : PascalCase ;
• méthodes : PascalCase ;
• paramètres : PascalCase ;
• variables locales : PascalCase ;
• membres privés : _PascalCase ;
• namespaces : stables, hiérarchiques et lisibles ;
• macros : uniquement si nécessaire, clairement nommées.

À éviter :

• noms trop courts sans signification ;
• préfixes techniques omniprésents sans valeur ;
• noms ambigus pour des pointeurs propriétaires ou non propriétaires.

5. Structure recommandée d’un fichier C++

Ordre recommandé :

1. en-tête légal si requis ;
2. include guard ou #pragma once ;
3. includes minimaux ;
4. namespace ;
5. déclaration du type ou des fonctions ;
6. implémentation en .cpp.

Règles :

• limiter les includes dans les headers ;
• préférer les forward declarations lorsque raisonnable ;
• séparer clairement l’interface et l’implémentation ;
• éviter les dépendances transversales cachées.

6. Style d’écriture

6.1 Accolades

Utiliser un style d’accolades cohérent sur tout le dépôt.
Toujours préférer la stabilité au mélange de styles.

6.2 const correctness

• marquer const tout ce qui doit l’être ;
• utiliser des références constantes pour éviter des copies inutiles ;
• rendre explicite l’intention de mutation.

6.3 Valeurs de retour

• éviter les pointeurs nus propriétaires ;
• retourner des types de valeur, références ou wrappers explicites selon le contrat ;
• documenter la sémantique de possession quand elle n’est pas évidente.

6.4 Conditions et branches

• privilégier les gardes précoces ;
• factoriser les expressions complexes dans des variables lisibles ;
• éviter la logique métier cachée dans des macros.

7. Règles spécifiques C++

• préférer std::unique_ptr à la possession manuelle ;
• utiliser std::shared_ptr seulement pour une propriété partagée réelle ;
• éviter new / delete directs hors cas spécialisés ;
• marquer override explicitement ;
• utiliser explicit sur les constructeurs à un paramètre quand nécessaire ;
• préférer std::string_view pour la lecture non propriétaire lorsque sûr ;
• faire attention à la durée de vie des références et vues.

8. Gestion des erreurs et robustesse

• utiliser les exceptions selon la politique du projet ou une alternative claire ;
• ne pas ignorer silencieusement un code d’erreur ;
• garder les invariants de classe simples et défendables ;
• valider les préconditions importantes ;
• documenter les contrats de possession et les cas d’échec.

9. Types d’éléments à revoir en priorité

Relire en priorité :

• types manipulant des ressources ;
• code concurrent ou multithread ;
• wrappers système ;
• interfaces publiques de bibliothèques ;
• sérialisation binaire ou réseau ;
• interopérabilité C / C++ / moteur.

10. Exemple complet recommandé

#pragma once

#include <memory>
#include <string_view>

namespace GalacticShrine::Users
{
    class UserProfileRepository;

    class UserProfileService final
    {
    public:
        explicit UserProfileService(std::shared_ptr<UserProfileRepository> Repository);

        bool UpdateDisplayName(std::string_view UserId, std::string_view DisplayName);

    private:
        std::shared_ptr<UserProfileRepository> _Repository;
    };
}

#include "UserProfileService.hpp"
#include "UserProfileRepository.hpp"

namespace GalacticShrine::Users
{
    UserProfileService::UserProfileService(std::shared_ptr<UserProfileRepository> Repository)
        : _Repository(std::move(Repository))
    {
    }

    bool UserProfileService::UpdateDisplayName(std::string_view UserId, std::string_view DisplayName)
    {
        if (UserId.empty())
        {
            return false;
        }

        if (DisplayName.empty())
        {
            return false;
        }

        return _Repository->UpdateDisplayName(UserId, DisplayName);
    }
}

11. Décision officielle recommandée

Standard officiel recommandé pour Galactic-Shrine C++ :

• utiliser PascalCase pour méthodes, paramètres et variables locales ;
• utiliser _PascalCase pour les membres privés ;
• appliquer RAII systématiquement ;
• séparer interface et implémentation clairement ;
• rendre explicites la possession, les coûts et la durée de vie.

12. Résumé exécutable

À appliquer dans tous les projets C++ Galactic-Shrine :

• PascalCase pour types, méthodes, paramètres et variables locales ;
• _PascalCase pour membres privés ;
• enum class, nullptr, override, explicit quand approprié ;
• pas de gestion mémoire propriétaire implicite ;
• headers légers, dépendances limitées ;
• contrats de possession clairs.