Avez-vous déjà vu un joueur de basket ou de football produire un jeu si simple et si efficace que vous vous demandez : pourquoi tout le monde ne joue-t-il pas comme ça ? Il semble n'utiliser que des techniques simples.
En tant que programmeur C++, j'ai eu la même pensée en explorant le code source de John Carmack : le code est si simple qu'on se demande pourquoi on n'arrive pas à écrire des logiciels comme lui.
Explorons quelques choix de conception du code source de Doom 3 et essayons de comprendre pourquoi le code, bien que simple, est très efficace.
Le 23 novembre 2011, id Software a perpétué la tradition et publié le code source de son moteur précédent. Ce code source a été passé en revue par de nombreux développeurs ; voici un exemple de retour sur Doom 3 de Fabien Sanglard (source originale) :
Doom 3 BFG est écrit en C++, un langage si vaste qu'il peut servir à produire du code excellent mais aussi des abominations qui vous feront saigner les yeux. Heureusement, id Software s'est contenté d'un sous-ensemble du C++ proche du « C with Classes », qui s'écoule dans le cerveau sans résistance :
- Pas d'exceptions.
- Pas de références (utiliser des pointeurs).
- Usage minimal des templates.
- Const partout.
- Des classes.
- Du polymorphisme.
- De l'héritage.
Pour résumer, seul un sous-ensemble de la norme C++98 est utilisé. Et voici quelques choix de conception de Doom 3 :
1. Fournir une classe de base commune avec des services utiles.
De nombreuses classes héritent de idClass :
idClass fournit les services suivants :
- Création d'instances.
- Gestion des informations de type.
- Gestion des événements.
2. Rendre la manipulation des chaînes facile
En général, les chaînes font partie des types les plus utilisés dans un projet ; de nombreuses opérations sont effectuées avec des chaînes, et nous avons besoin de fonctions pour les manipuler.
Doom 3 définit la classe idStr, qui contient presque toutes les méthodes utiles pour manipuler les chaînes — pas besoin de définir vos propres méthodes, comme c'est le cas avec de nombreuses classes de chaînes fournies par d'autres frameworks.
3. Le code source est fortement découplé du framework GUI (MFC)
Dans de nombreux projets utilisant MFC, le code est fortement couplé à ses types, et l’on trouve des types MFC partout dans le code.
Dans Doom 3, le code est fortement découplé de MFC ; seules les classes de l'IHM en dépendent directement, comme le montre la requête CQLinq suivante :
Ce choix a un impact important sur la productivité : en effet, seuls les développeurs de l'IHM doivent composer avec le framework MFC, et les autres développeurs n'ont pas à perdre de temps avec MFC.
4. Il fournit une très bonne bibliothèque utilitaire (idlib)
Dans presque tous les projets, les types les plus utilisés sont les classes utilitaires, comme le montre le résultat de la requête suivante :
Comme on peut le constater, les plus utilisées sont les classes utilitaires. Si les développeurs C++ n'utilisent pas un bon framework utilitaire, ils peuvent finir par passer une grande partie de leur temps de développement à gérer la couche technique.
idlib fournit des classes utiles avec toutes les méthodes nécessaires pour gérer les chaînes, les conteneurs et la mémoire, ce qui facilite le travail des développeurs et leur permet de se concentrer davantage sur la logique du jeu.
5. L’implémentation est très facile à comprendre
Doom 3 implémente un compilateur maison, et comme les développeurs C++ le savent, développer des parseurs et des compilateurs n'est pas une tâche facile. Cependant, l'implémentation de Doom 3 est très facile à comprendre, et son code est très propre.
Voici le graphe de dépendances des classes utilisées par le compilateur :
Et voici un extrait du code source du compilateur :
Nous avons déjà étudié le code source de nombreux parseurs et compilateurs, mais c'est la première fois que nous rencontrons un compilateur dont le code source est si facile à comprendre — et c'est pareil pour l'ensemble du code source de Doom 3. C'est magique. En explorant le code source de Doom 3, on ne peut s'empêcher de dire : WOW, c'est magnifique !
Pour résumer, le code source de Doom 3 est très propre, facile à comprendre et à maintenir, et il n'utilise qu'un sous-ensemble de la norme. Aucune technique avancée n'est employée, et il suit les bonnes pratiques de base en matière de conception, de nommage et de formatage du code.
On peut dire que le secret de John Carmack était le principe KISS, tel que défini sur Wikipédia :
KISS is an acronyme for "« Keep it simple, stupid » (reste simple, idiot)" as a design principle noted by the U.S. Navy in 1960.[1][2] The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicité should be a key goal in conception and unnecessary complexity should be avoided. The phrase has been associated with aircraft engineer Kelly Johnson (1910–1990).[3] The term "KISS principle" was in popular use by 1970.[4] Variations on the phrase include: "Keep it simple, silly", "keep it short and simple", "keep it simple and straightforward",[5] "keep it small and simple" and "keep it stupid, simple".[6]Ce qui est intéressant dans cette définition, c'est l'affirmation suivante :
Le principe KISS stipule que la plupart des systèmes fonctionnent mieux s'ils restent simples plutôt que compliqués.Quelles leçons devons-nous tirer en adoptant les nouvelles normes C++ ?
Les nouvelles normes ont introduit de nombreuses fonctionnalités intéressantes. Supposer que l'utilisation de toutes ces fonctionnalités rendra automatiquement votre code plus efficace est une mauvaise idée ; beaucoup de nouvelles fonctionnalités sont plus utiles pour développer des bibliothèques génériques, en particulier toutes celles liées à la programmation générique.
Ne vous forcez pas à utiliser toutes les nouvelles fonctionnalités ; n'utilisez une fonctionnalité que lorsqu'elle est vraiment nécessaire et qu'elle aide à rendre votre code meilleur ou plus efficace. Par exemple, cet intéressant article parle des inconvénients de l'abus du mot-clé auto.