Présentation de mon dernier projet en C++

Version imprimable

03/09/2023, 16h07
BluMonky

Présentation de mon dernier projet en C++

Salut à tous,
Depuis le début du mois, j'ai commencé à créer un petit jeu en invite de commande en C++ avec Visual Studio Community.
J'ai programmé ce "jeu" pour tester mes compétences en C++, ce jeu est un fan game basé sur le film Hitman le Cobra et je souhaite donc le partager ici pour avoir des retours, pour connaître quelles sont les erreurs que je devrais anticiper lors de la suite de mon apprentissage et pour connaître les notions qui me seront plus utiles pour ce genre de projet, pour me diriger vers mon projet final, développer un moteur de jeu 3D et ainsi créer mon propre jeu vidéo.
Voici le lien du jeu : https://drive.google.com/drive/folde...i0?usp=sharing
Et voici son GitHub : https://github.com/BluMonky/Hitman-le-Cobra-Fan-Game
Merci d'avance.
04/09/2023, 12h40
bacelar

Petites remarques à 2 balles rapides :
- Utilisez des conventions de nommages cohérentes (pas du CAPSLOCK puis du snake_style, etc ...)
- Beaucoup de commentaires inutiles, prenez le temps de bien nommer vos champs, variables, fonctions, etc ...
04/09/2023, 15h05
BluMonky

Citation:

Envoyé par bacelar

Petites remarques à 2 balles rapides :
- Utilisez des conventions de nommages cohérentes (pas du CAPSLOCK puis du snake_style, etc ...)
- Beaucoup de commentaires inutiles, prenez le temps de bien nommer vos champs, variables, fonctions, etc ...

Ok merci :ccool:
Je tâcherai d'y faire attention lors de mon prochain projet.
Plus précisément, à quoi doit ressembler exactement la syntaxe d'un nom d'élément et que doivent décrire exactement les commentaires ?
04/09/2023, 15h32
bacelar

Citation:

à quoi doit ressembler exactement la syntaxe d'un nom d'élément

Les conventions de codage, il faut juste les définir (ou plus couramment, en choisir une déjà construite) et les respecter, pour simplifier le code (et éviter des erreurs d'inattention).

Citation:

et que doivent décrire exactement les commentaires ?

Ça dépend du type de commentaire.
Il y a les commentaires pour la documentation technique (Doxygen, ...)
Mais les commentaires qui trainent dans le code, c'est pour alerter le lecteur sur un truc pas évident.
Donc, ne pas noyer ces messages d'alerte avec du bruit de commentaire sans valeurs (et souvent pas à jour donc dangereux).
Avant de penser à mettre un commentaire, on cherche à expliciter la logique du programme avec des noms d'identifiants "expressifs".
04/09/2023, 16h17
BluMonky

Citation:

Envoyé par bacelar

Les conventions de codage, il faut juste les définir (ou plus couramment, en choisir une déjà construite) et les respecter, pour simplifier le code (et éviter des erreurs d'inattention).

Ça dépend du type de commentaire.
Il y a les commentaires pour la documentation technique (Doxygen, ...)
Mais les commentaires qui trainent dans le code, c'est pour alerter le lecteur sur un truc pas évident.
Donc, ne pas noyer ces messages d'alerte avec du bruit de commentaire sans valeurs (et souvent pas à jour donc dangereux).
Avant de penser à mettre un commentaire, on cherche à expliciter la logique du programme avec des noms d'identifiants "expressifs".

Compris, j'y ferai donc attention dans mes prochains programmes.

Salut,

Citation:

Envoyé par BluMonky

à quoi doit ressembler exactement la syntaxe d'un nom d'élément et que doivent décrire exactement les commentaires ?

Salut,

Pour ce qui est des identifiants
(je préfère parler d'identifiants plutôt que de "noms" pour éviter toute confusion ;) ) il faut faire en sorte qu'ils décrivent par eux mêmes la "raison d'être" de ce qu'ils identifient, par exemple:

pour un type de donnée, tu peux choisir le mot qui désigne le "concept" que tu veux représenter : Voiture, Avion, Pistolet, Personnage représentent des concepts que tout le monde connait
pour une donnée (qu'il s'agisse d'une constante ou d'une variable), choisi un idientifiant qui explique clairement l'usage qui en sera fait comme voitureDeJhon,escadrilleDavionDeChasse, pistoletAViseeLaser, ...
pour les fonctions essaye d'en décrire l'objectif. Ce sera sans doute sous forme d'un verbe (et de ses compléments), par exemple : trier ou trierParOrdreCroissant ...
Si la fonction agit d'avantage comme une question dont tu attends la réponse, essaye de poser la question: estEnVie, estActif, aDesMunitions ...

Cela va permettre à ton code de "raconter une histoire" à la personne qui le lit, ce qui permettra à la personne qui le lit de ... comprendre ton code plus facilement ;)

Pour ce qui est des commentaires

De manière générale, il faut partir du principe que le meilleur commentaire, ce sera toujours celui que l'on n'aura pas besoin d'écrire.

Si, en relisant ton code, tu te dis "Houlala... je n'arrive déjà plus à comprendre ce que je voulais faire, je vais ajouter un commentaire", c'est que tu as déjà loupé quelque chose...

Il y a de fortes chances que, si tu change le nom d'une variable ou d'une fonction, tu puisse arriver à faire en sorte que ton code s'explique par lui meme, en commencant à te "raconter l'histoire" de ce qu'il fait.

Autrement, tu as trois grosses catégories de commentaires:

a- les "cartouches"
Il s'agit le plus souvent de commentaires placés avant la définition d'un type de donnée (classe, structure ou énumération) ou avant le prototype d'une fonction qui tente d'expliquer la raison d'être de l'élément commenté.

Si tu utilises un format approprié (par exemple le format reconnu par doxygen) ils te permettront de générer automatiquement la documentation de ton projet Par exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 /** @brief représente le niveau d'agressivité envers le joueur * * La réaction des rencontres faites par le joueur à son encontre dépendra * de leur niveau d'agressivité : * * Affole : la rencontre s'enfuit de manière désordonnée à l'approche du joueur * Apeure : la rencontre essaye de se cacher à l'approche du joueur * Craintif : la rencontre observe le joueur avec suspiscion * Neutre : la rencontre semble ne pas faire attention au joueur * Rancunier : la rencontre n'attend d'une raison valable pour attaquer le joueur * Agressif : la rencontre attaque le joueur "à vue" */ enum class Agressivite{ Affole, Apeure, Craintif, Neutre, Rancunier Agressif, };
(Evidemment, on peut faire la même chose pour les fonctions, je n'ai simplement pas d'exemple en tête pour l'instant ;) )
Ce genre de commentaire explique tout ce qu'il faut savoir pour utiliser "correctement" l'énumération "Agressivite", sans donner plus de détail que nécessaire.

Si tu abandonne ton projet pour deux mois, un an ou même dix ans, lorsque tu reviendra dessus et que tu reliras ton commentaire, tu sauras exactement pourquoi tu as créé cette énumération, et l'objectif du commentaire sera atteint ;)

Les commentaires à visée didactiques :

Il y a un fait indéniable: c'est que le code que l'on va présenter à quelqu'un qui découvre à peine la programmation va plus être perçu par "l'élève" comme un sorte "d'incantation magique" que comme quelque chose de parfaitement structuré dont chaque instruction a sa propre raison d'être et, surtout, d'excellentes raisons de se trouver exactement à cet endroit particulier plutôt qu'ailleurs.

Si l'on veut que "l'élève" puisse avoir "la moindre chance" d'arriver à comprendre ce que fait le code donné en exemple, il va falloir trouver un moyen de lui expliquer et, de préférence, trouver un moyen pour que les explications soient "directement rattachées" à la partie du code qu'elles doivent expliquer.

Le meilleur moyen d'y parvenir étant ... d'introduire dans le code ce que l'on peut appeler des "commentaires (à visée) didactiques". Par exemple (tiré de ton propre code):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 /* pour chaque actions se trouvant dans la liste * des actions potentielles du joueur */ for (auto& action : joueur.liste_actions) { /* si l'action envisagée est de classe "combat" * on rend l'action en question accessible, autrement * (c'est à dire : si l'action est de classe "menu") * on la rend inaccessible. */ if (action.classe == "combat") { action.avaible = true; } else if (action.classe == "menu") { action.avaible = false; } }
(Note au passage que le fait d'avoir exprimé la logique mise en place pourrait t'inciter à l'améliorer d'une manière ou d'une autre, ce qui pourrait être bénéfique au final ;) )

On remarquera que ce sont des commentaires qui paraphrasent énormément le code, ce qui est généralement une mauvaise chose (*). Cependant, leur présence est tolérée -- pour ne pas dire "rendue indispensable" -- par le fait que le seul but de ce code et des commentaires qui y sont associés est justement de permettre à la personne qui lit le code de comprendre "ce qui est fait et pourquoi".

Et pourtant, si la présence de tels commentaires et tolérée dans un code qui a pour but de permettre à "un élève" de comprendre le code présenté en exemple, ils ne devraient jamais se retrouver dans un code de "production" ;)

(*) Généralement, les commentaires qui paraphrasent le code sont très mal vus parce qu'il y a une très forte probabilité pour qu'ils ne soient pas mis à jour si le code vient à être modifié.

On risque alors de se retrouver avec des commentaires qui "expliquent quelque chose" alors que le code "fait autre chose", ce qui embrouille l'esprit du lecteur bien plus que ce que les commentaires -- s'ils avaient été à jour -- n'auraient pu l'aider à comprendre.

Et c'est d'autant plus vrai que la plupart des gens préféreront lire les commentaires, qui ont l'avantage d'être écrits sous une forme "facilement compréhensible" plutôt que le code qui reste -- quoi qu'il arrive -- plutôt "cryptique".

Les commentaires totalement inutiles

La dernière catégorie est celle qui regroupe "tous ces commentaires" qui ... ne servent absolument à rien parce qu'ils n'apportent aucune "plus value" dans le code.

Par exemple :

Code:

a = a *2; // multiplie la valeur de a par deux

Sans blagues ??? ... j'étais persuadé que cette ligne avait pour objectif d'additionner les valeurs de b et de c et de donner le résultat à d ....
(et si tu ne crois pas celle-là, je t'en raconterai une autre ;) )

Dans bien des cas, les commentaires pourraient être rendus inutiles simplement en améliorant le code, entre autre, au niveau du respect des principes SOLID dont (principalement, mais pas que) le fait de respecter le SRP (Single Responsability Principle ou principe de la responsabilité unique), qui correspond au S de SOLID.

Par exemple, sur la même page que l'exemple précédent, on trouve, dans une seule et unique fonction les commentaires:

Code:

// Boucles rendant les actions pour le combat disponibles et celles pour le menu principal indisponibles

(ligne 29)

Code:

// Sert à afficher les cinématiques

(ligne 82)

Code:

// Initialisation des variables pour le combat

(ligne 91)

Code:

// Remise des entités à leur état d'origine

(ligne 157) et, à la fin de la fonction

Code:

// Boucles rendant les actions pour le menu principal disponibles et celles pour le combat indisponibles

(ligne 181)

Je ne peux m'empêcher de penser ces commentaires démontrent que tu avais déjà au minimum "l'intuition" que "quelque chose cloche" dans ton code, que les différentes étapes décrites par les commentaires, que le code permettant à ces étapes d'exister n'avait "aucune raison" d'être regroupé au sein d'une seule et unique fonction.

Et, en vertu du SRP, ton intuition était parfaitement justifiée, car tu te retrouve avec une seule fonction (la fonction combat) qui se retrouve à faire ... cinq choses différentes. Qui se retrouve avec cinq responsabilités. Ce qui en fait quatre de trop.

Si tu avais fait en sorte que chacune de ses responsabilités soit prise par une fonciton spécifique, le code de la fonction combat aurait pu se limiter (par exemple) à quelque chose comme
Code:

1 2 3 4 5 6 7 8 bool combat(entity& joueur, entity& ennemi, int& niveau){ std::chrono::milliseconds pause(500); changeActionMode(joueur,"combat"); changeActionMode(ennemi,"combat"); jouerCinematiques(niveau); battezVous(joueur, ennemi); resetApresCombat(joueur, ennemi); }
et chacune des fonctions appelée aurait pu correspondre à une étape bien particulière, ce qui aurait eu l'énorme intérêt de ... permettre de les réutiliser "ailleurs" en cas de besoin ;)

Mais, du coup, les commentaires pourraient parfaitement être supprimer sans nuire à la compréhension car ... le code nous "raconte" déjà la même histoire que celle que tu as décidé de nous raconter au travers des commentaires ;)

05/09/2023, 10h55
Guesset

Bonjour,

Si les conseils de koala01 sont tous intéressants, j'aurais cependant une préférence pour la souplesse, qui ne manque pas de rigueur, de la proposition de bacelar.

En effet, les règles sont d'autant mieux suivies qu''elles correspondent au mode de fonctionnement du développeur. La rigueur intégrée est plus importante qu'une rigidité imposée (et souvent mal suivie).

Ensuite, il y a des cas où il faut prévoir d'autres principes, d'autres règles. Par exemple, que le code "raconte une histoire" est certes à privilégier mais ne s'avère pas systématiquement possible. En effet, cela suppose une certaine linéarité qui n'est pas nécessairement présente. Par exemple, une transformée rapide de Fourrier, un traitement récursif ou croisé semblent difficiles à faire entrer dans le moule.

Les commentaires qui ne servent à rien (i.e. qui n'expliquent rien) sont effectivement à bannir. On pourrait penser que tout code qui a besoin de commentaires explicatifs devrait être réécrit, mais cela me contraindrait à reprendre trop de mon code. Pour i > 0, écrire bool isPwr2(uint64_t i) { return !(i & (i-1)); } reste un plaisir pervers auquel renoncer serait difficile :oops: (et il y a pire - ou mieux ? - l'utilisation de l'assembleur popcnt qui retourne directement le nombre de bits à 1).

Le recours systématique à une multiplication d'appels de fonctions peut rendre le code moins lisible (spaghettis d'appels) et moins efficace (un appel a un coût). S'il faut éviter les fonctions trop longues, il faut également éviter les fonctions trop courtes (même si on peut espérer un inline salvateur). Un principe que j'applique (mais je suis loin d'être un modèle) est de ne pas avoir de fonctions petites qui ne soient appelées qu'à un seul endroit.

Les noms de variables longs me laissent perplexes. Ils conduisent souvent à des expressions qui se répandent sur plusieurs lignes devenant ainsi difficiles à lire. Sans chercher des noms ultras courts, j'ai tendance à privilégier l'homogénéité (par exemple, joueur1 et joueur2 au lieu de joueur et ennemi).

Je ne cherche pas à défendre un ensemble de règles contre un autre mais juste à montrer qu'il existe toujours plusieurs approches.

En résumé, nous avons besoin de règles, mais nous devons les choisir avec soin en sachant qu'elles ne sauraient être parfaites et universelles.

La présentation du code est également importante. Bien sûr, il y a le respect des indentations mais ce n'est qu'une facette. Les lignes vides d"aération", la (non)création de bloc même pour une seule instruction, l'acceptation ou non des lignes multi instructions sont autant d'éléments à prendre en compte.

Dans le cas d'un développement en équipe, les règles sont imposées, ce qui, au moins, limite les cogitations :calim2:.

Salutations
05/09/2023, 18h56
BluMonky

Citation:

Envoyé par koala01

...

Salut, merci pour tes conseils, pour ce qui est des concepts et des conseils sur la POO, je n'y suis pas encore mais ça me sera sûrement très utile.
05/09/2023, 19h44
koala01
Citation:

En résumé, nous avons besoin de règles, mais nous devons les choisir avec soin en sachant qu'elles ne sauraient être parfaites et universelles.

Tu as tout à fait raison, à ceci près que les règles que l'on égrène se doivent essentiellement d'être adaptées à la personne à qui on les adresse.

Tu sembles seulement avoir oublié que @BluMonky fait ses toutes premières armes et qu'il lui fallait donc des règles qui soient
- faciles à comprendre
- faciles à mettre en oeuvre et
- adaptées au plus grand nombre
Tu remarqueras que les règles que je lui ai proposées respectent effectivement ces trois conditions ;)

Et tu remarqueras que j'ai essayé -- dans la mesure du possible -- d'éviter l'absolu, justement, pour laisser place à l'interprétation lorsque @BluMonky aura pris un peu de bouteille tout en lui donnant l'occasion de les garder comme "fil d'Ariane".

Il se peut que certains identifiants aient vraiment été mal choisis et que leur seul avantage soit de m'avoir permis de donner une idée précise (bien qu'exagérée) de ce que l'on peut considérer comme "un identifiant décrivant l'usage qui sera fait"

Excuses moi pour cela. Il se fait que j'ai écrit ma réponse avec un bras dans la manche de ma veste, juste avant de partir bosser ;)
06/09/2023, 15h55
Guesset

Bonjour koala01,

Citation:

Envoyé par koala01

Tu as tout à fait raison, à ceci près que les règles que l'on égrène se doivent essentiellement d'être adaptées à la personne à qui on les adresse...

C'est vrai que mes propos peuvent apparaître critiques même si ce n'était pas le but :oops:. J'ai trop vu des règles pertinentes mais contraignantes qui n'étaient pas appliquées car ressenties comme des carcans. Or la première qualité des règles est d'être pleinement acceptées, intégrées. C'est rarement possible sans aménagements personnels.

Les règles que tu proposes sont excellentes. J'ai essayé seulement de mettre en évidence le caractère relatif de toute règle afin que @BluMonky se sente libre de les adapter à sa personnalité et son type de code. Si j'avais pris mes règles de code, elles auraient certainement mérité bien plus de critiques encore (j'ai un code orienté optimisation de traitement d'image qui, bien que j'essaye d'être rigoureux, n'est souvent pas un exemple de lisibilité).

Je dois refuser tes excuses car il n'y a aucune raison d'en présenter. Nous n'avons pas la même logique de nommage, mais ce n'est pas très important. L'important est d'en avoir une. Je pense qu'un développeur est un auteur, son style de code lui sera nécessairement personnel (je me souviens d'un livre qui disait que le codage était aussi de la conception).

Donne n'importe quel code opérationnel à un développeur. Les probabilités qu'il en déduise la nécessité d'une réécriture tendent vers 1. Personne n'aime mettre les chaussons de quelqu'un d'autre :D

Salut