Discussion :

[francois1990]

Bonjour à tous, je suis nouveau dans la communauté.
effectivement rien de plus anormal, puisque je débute en C++.

Certain font déjà demi-tour en se disant... un débutant, encore un qui veux créer un MMoRPG. :p
Et bien non, mon premier but est de créer des petits jeux basiques sur console (pendu, trouver le mots, pacman, etc) vous saisissez l'idée.
par la suite, évidemment, je ne veux pas rester coincer dans le mode console, j'aimerai pouvoir créer des petits jeux (en exemple: heu ... le genre de jeux qu'on retrouve sur tablette). en fait, je n'aimerai pas ... je veux (on m'a dis que vouloir c’était déjà une belle preuve de détermination) :p

je suis conscient du travail que cela représente... et surtout du long l'apprentissage. c'est pour cela que je le dis tout de suite, je ne compte pas bruler les étapes et faire ca bien!

bon oui, c'est vrai j'ai commencer a apprendre le c++ il y a 3 jours et mes ambitions sont déjà importantes... oui mais, ne faut il pas avoir un but reel pour avancer?

donc voila, je vais vous présenter un code écrit hier. le but était de créer une fonction et de l'appeler dans le main.

la fonction permet d'ajouter de l'xp a un xp initial et de déterminer le lvl en fonction de l'xp initial.

j'aimerai avoir quelques éclaircissement sur mon code :

- est ce que cette fonction est utile (pour que mon main() soit moins lourd visuellement)
- est ce qu'il y a moyen d’améliorer cette fonction (pas d'y ajouter des choses, mais plutôt de simplifier son écriture)

enfin, tout conseil est bon a prendre. n’hésitez pas.
je veux vraiment coder proprement.
s'il vous plais, essayez de ne pas parlez trop technique pour l'instant, on risque de ne pas se comprendre... enfin, essayez, juste un peu.

voila le code xplvl.cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
#include "xplvl.h"
 
void ajouteXp(int& xpIni, int newXp, int& gainLevel)
{
    xpIni += newXp;
 
    if (xpIni>=0 && xpIni<100)
    {
        gainLevel = 0;
    }
    if (xpIni>=100 && xpIni<300)
    {
        gainLevel = 1;
    }
    if (xpIni>=300 && xpIni<600)
    {
        gainLevel = 2;
    }
    if (xpIni>=600 && xpIni<1000)
    {
        gainLevel = 3;
    }
    if (xpIni>=1000 && xpIni<1600)
    {
        gainLevel = 4;
    }
    if (xpIni>=1600 && xpIni<2400)
    {
        gainLevel = 5;
    }
    if (xpIni>=2400 && xpIni<3600)
    {
        gainLevel = 6;
    }
    if (xpIni>=3600 && xpIni<4800)
    {
        gainLevel = 7;
    }
    if (xpIni>=4800 && xpIni<6200)
    {
        gainLevel = 8;
    }
    if (xpIni>=6200 && xpIni<7900)
    {
        gainLevel = 9;
    }
    if (xpIni>=7900)
    {
        gainLevel = 10;
    }
}

voila le code xplvl.h :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
#ifndef XPLVL_H_INCLUDED
#define XPLVL_H_INCLUDED
 
void ajouteXp(int& xpIni, int newXp, int& gainLevel);
// fonction qui ajoute l'xp recue à l'xp initial et calcul gain level en fonction de l'xp^initial.
// variable entrente : xpini, newxp, gain level.
// aucune valeur retournée. car référence.
 
#endif // XPLVL_H_INCLUDED

et mon main :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
 
#include <iostream>
#include "xplvl.h"
using namespace std;
 
int main()
{
    int xpJoueur(0), xpGagne(0), level(0);
    cout<<"joueur a "<<xpJoueur<< "xp."<<endl;
 
    cout<<"joueur gagne 30 xp."<<endl;
    xpGagne = 30;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 35 xp."<<endl;
    xpGagne = 35;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 125 xp."<<endl;
    xpGagne = 125;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 113 xp."<<endl;
    xpGagne = 113;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 200 xp."<<endl;
    xpGagne = 200;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 127 xp."<<endl;
    xpGagne = 127;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 321 xp."<<endl;
    xpGagne = 321;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 186 xp."<<endl;
    xpGagne = 186;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 54 xp."<<endl;
    xpGagne = 54;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 652 xp."<<endl;
    xpGagne = 652;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 1243 xp."<<endl;
    xpGagne = 1243;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
 
    return 0;
}

voila ce que donne la console :

[white_tentacle]

Plusieurs remarques :

- la première, c’est le nom des paramètres. En ce qui me concerne, j’aime bien les paramètres avec des noms explicites, pas trop les abréviations. Donc plutôt que xpIni, xpInitial.
- la deuxième, c’est que les paramètres doivent avoir un nom qui correspondent à ce qu’il sont / font. Or ici, je vois :
* xpIni qui est aussi la valeur utilisée pour les xps de retour --> pourquoi pas plutôt playerXp ?
* newXp qui est en réalité les xps supplémentaires --> additionalXp ?
* gainLevel qui est en réalité le niveau « actuel » du personnage, non ?
- la troisième, c’est que ajouter des xps et savoir quel est le niveau à partir du nombre d’xps sont deux choses différentes, non ? Donc je ferais plutôt une fonction qui donne, à partir d’un nombre d’xps donnés, le niveau actuel du personnage.

Voilà pour le premier jet de remarques.

[prgasp77]

Bonjour et bienvenu !

C'est une bonne chose que tu te rendes compte du travail qu'il te faudra accomplir, que tu souhaites avancer progressivement et que tu te focalises sur ta façon de faire autant que sur le résultat. Le code que tu as présenté est un bon début, il a l'avantage d'être simple à lire. Et ça c'est beaucoup. Voici quelques axes d'amélioration :

1. Prototype de ta fonction ajouteXp
   • Cette fonction prend un gain d'xp en entrée et sors un total d'xp et un niveau. Elle fait donc deux choses. Devrait-il y avoir deux fonctions ? Ces deux fonctions auraient-elles à gagner en synergie en étant deux méthodes d'une même classe dont les objets représenteraient le niveau d'un personnage ... ou pour être plus précis quelque chose qui peut avoir un niveau ?
   • Dans le cas contraire (on reste sur l'idée d'une unique fonction), il est d'usage de mettre tous les paramètres de sortie (ici gainLevel et xpIni) "à côté" dans la liste des paramètres (ex : void ajouteXp(int& xpIni, int& gainLevel, int newXp)
   • Il serait de bon aloi de documenter ta fonction en explicitant ce qu'elle fait, ce qu'elle prend en entrée, ce qu'elle retourne en sortie, ses effets de bords, son comportement quand l'entrée n'est pas telle qu'attendue, etc. Cette documentation peut prendre la forme de commentaires C++, tout simplement.
   
   
2. Séparation des données et de l'implémentation.
   Dans le corps de la fonction ajouteXp, des constantes apparaissent définissant les limites de niveau. Idéalement, ces données seraient séparées du traitement, définies dans une structure de ton choix (un liste de constantes, un tableau, ou tout autre chose). Ton implémentation utiliserait ensuite ces données pour calculer le niveau correspondant à l'XP. De la sorte, si tu veux modifier une limite de niveau, ou définir la limite pour un nouveau niveau, il n'y a qu'une partie du code à changer.
3. Divers
   
   • Enlève-moi donc cet horrible using namespace std et prends l'habitude, dès maintenant, d'écrire std::cout, std::vector, std::string, etc. Ce n'est pas si long, et ça a l'avantage d'éviter les conflit de noms et d'expliciter immédiatement au lecteur qu'il s'agit de classes/d'objet de la SLT et non des définitions locales.
   • Montre nous tes options de compilations que l'on te les pourrisse un peu

Au sujet de ton apprentissage à proprement parler, quel(s) livre(s)/tutoriel(s) suis-tu ? Fait bien attention à ce qu'il(s) soient récents (pas après 2008--2010).
Au plaisir de te voir fréquemment parmi nous.

[francois1990]

white_tentacle, merci pour ta réponse.
j'ai pris en compte tes remarque quant aux noms donné dans ma fonction.
il est vrai qu'avec les noms que tu m'a proposé, c'est nettement plus explicite.

pour ton troisième point : je me suis justement dis, qu'une fonction ne doit elle pas être bien fournie pour être intéressante?

l’expérience d'un joueur évolue tout au long d'un jeu, en fonction de l’expérience, le niveau du joueur augmente. les deux sont donc lié... plutôt que de faire deux fonction, je l'ai réduite à une seule. je pensais que c'était une bonne chose.

quel est le réel problème de cette fonction à deux utilités?



prgasp77, tu as toi aussi pris le temps de répondre a mes question, milles merci.
que veux tu dire par : "Ces deux fonctions auraient-elles à gagner en synergie en étant deux méthodes d'une même classe dont les objets représenteraient le niveau d'un personnage ... ou pour être plus précis quelque chose qui peut avoir un niveau ?"

en attendant, j'ai tout de même suivi ton conseil de mettre les paramètres de sorties les uns a coté des autres. c'est un petit détail, mais a la lecture c'est plus fluide.

pour la documentation de la fonction, en fait j'ai fais un petit résumé dans mon fichier .h
il y a juste son comportement quand l'entrée n'est pas telle qu'attendue, que je n'ai pas fait (d'ailleur je n'ai pas prevu ca non plus)
pourquoi l'entrée ne serait elle pas telle qu'attendue ?
en programment un jeu ou un personnage gagnera de l'xp, l'xp gagnée est implantée dans le jeu pour chaque mission, donc si la programmation est bien faite, il ne devrait pas y avoir de problème au niveau des entrées non?

pour le point 2., je t'avoue ne pas avoir trop compris :p

"prends l'habitude, dès maintenant, d'écrire std::cout, std::vector, std::string, etc." et je dois noter cela pour chaque type de variable utilisé?


"Montre nous tes options de compilations que l'on te les pourrisse un peu" heu, je souffre vraiment de débutantisme la :p


pour l'instant j'utilise les cours du sites du zero initialement. c'est pas le top, mais bon :/

[prgasp77]

prgasp77, [...] que veux tu dire par : "Ces deux fonctions auraient-elles à gagner en synergie en étant deux méthodes d'une même classe dont les objets représenteraient le niveau d'un personnage ... ou pour être plus précis quelque chose qui peut avoir un niveau ?"

Je me suis un peu emballé là ... ces notions arriveront plus tard quand tu apprendras la programmation orientée objet. Mais je reste sur mon idée que deux fonctionnalités = deux fonctions. Moins une fonctions fait de choses, plus elle est riche, car précise, concise, et exempte de bug.

pour la documentation de la fonction, en fait j'ai fais un petit résumé dans mon fichier .h

Très bien.

il y a juste son comportement quand l'entrée n'est pas telle qu'attendue, que je n'ai pas fait (d'ailleur je n'ai pas prevu ca non plus)
pourquoi l'entrée ne serait elle pas telle qu'attendue ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int xpIni = 0;
int gainLevel = 0;
ajouteXp(int& xpIni, -1, int& gainLevel);

en programment un jeu ou un personnage gagnera de l'xp, l'xp gagnée est implantée dans le jeu pour chaque mission, donc si la programmation est bien faite, il ne devrait pas y avoir de problème au niveau des entrées non?

Il y en aura. Un jour. Sûr. 100%. Un programme ça vie, ça évolue. On revient sur son code des années après. Certains jours on a la tête ailleurs. D'autres développeurs peuvent se joindre au projet. bref, quand (et pas "si") ça arrive, on est face à un bug. Si la fonction trucmuche est documentée avec un paragraphe disant "si en entrée on me donne 18, alors la sortie est invalide" ce sera d'une précieuse aide le jour où ça arrivera.

pour le point 2., je t'avoue ne pas avoir trop compris :p

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**
 * Retourne le niveau d'un personnage ayant totalisé xp points d'expérience.
 */
int niveau(int xp)
{
    const int[] limites_de_niveau = { 0, 1000, 3000, 6000, 10000 }; /* YEAH! ol' style C++98 !! */
    const std::size_t niveau_max = sizeof(limites_de_niveau) / sizeof(limites_de_niveau[0]); /* Pour info, défini niveau_max à 5. Cette construction est classique et permet de récupérer, dans certains cas, le nombre d'éléments d'un tableau. */
 
 
    for (std::size_t niveau = 0 ; niveau < niveau_max ; ++niveau)
    {
        if (xp >= limites_de_niveau[niveau])
        {
            return niveau;
        }
    }
 
    return niveau_max;
}

"prends l'habitude, dès maintenant, d'écrire std::cout, std::vector, std::string, etc." et je dois noter cela pour chaque type de variable utilisé?

Si tu écris plus de dix fois le même type au sein d'une même fonction, dans ma grande mansuétude, je vais tolérer using std::quelquechose;, qui dans le bloc courant, permet d'utiliser quelquechose comme tu utiliserais std::quelquechose.

"Montre nous tes options de compilations que l'on te les pourrisse un peu" heu, je souffre vraiment de débutantisme la :p

Normal. Quel environnement de développement utilises-tu ? Système d'exploitation ? IDE (Code::Blocks ? Microsoft Studio ? ...) ? On te guidera pour activer ce qu'on appelle les warnings de compilation qui demande au compilateur de te relever tous les éléments qui lui semblent étranges et qui pourraient être une erreur ou une mauvaise habitude.

pour l'instant j'utilise les cours du sites du zero initialement. c'est pas le top, mais bon :/

Effectivement, pas top. Un habitué des cours de dvp aurait une suggestion avant qu'il ne soit trpo tard ?

[koala01]

white_tentacle, merci pour ta réponse.
j'ai pris en compte tes remarque quant aux noms donné dans ma fonction.
il est vrai qu'avec les noms que tu m'a proposé, c'est nettement plus explicite.

pour ton troisième point : je me suis justement dis, qu'une fonction ne doit elle pas être bien fournie pour être intéressante?

Non, au contraire : il existe un principe nommé SRP (pour Single Responsability Principle ou, si tu péfères "principe de la responsabilité unique" en francais) qui stipule que chaque fonction, chaque type ne doit s'occuper que d'une seule et unique chose, mais qu'il/elle doit s'en occuper correctement.

L'idée au niveau des fonction est que tu auras surement des fonctions dont la responsabilité unique est complexe, mais que tu peux créer des fonctions beaucoup plus simples ne prenant qu'une partie bien spécifique de cette responsabilité en charge et que ces fonctions plus simples seront plus facilement utilisables, par exemple, en changeant l'ordre dans lequel elles sont appelée.
Imaginons que tu veuille créer une fonction (c'est in, la domotique ) qui lance le café, fait la lessive, fait la vaisselle et sort le chien avant d'aller faire les courses.

Tu peux, bien sur, créer une seule fonction qui fait tout cela à la suite. Mais ca te fera une fonction de surement 150 lignes .


Un peu plus tard, tu risque d'avoir besoin d'une fonction qui fait la lessive, sort le chien, va faire les courses, fait la vaisselle avant de préparer le café. Tu auras remarqué qu'il s'agit de faire exactement les mêmes choses, mais dans un ordre différent. Si tu avais 150 lignes de code dans la première fonction, tu auras aussi 150 lignes dans celle-ci

Et comme tu es fainéant (en tout cas, je le suis moi), tu vas te "contenter" d'un gros copier / coller du code avant de le réorganiser pour qu'il s'exécute dans le bon ordre.

Plus tard encore, tu voudras une troisième fonction qui fait exactement les mêmes choses dans un ordre différent. Puis une quatrième, une cinquième et une sixième... Et comme il est possible d'avoir 120 combinaisons différentes, tu pourras en rajouter encore tout plein

Mais, un jour, tu auras un client qui se plaint que son chien pisse systématiquement sur le tapis persan lorsqu'on fait les courses tout de suite après avoir sorti le chien. L'un dans l'autre, cette description du problème devrait t'inciter à essayer de corriger une bonne 30aine de fonctions. Sauf que tu peux avoir la certitude que tu en oubiera l'une ou l'autre.

Et puis, le problème n'est pas que l'on aille faire les courses après avoir sorti le chien... c'est qu'on sort le chien 25 minutes alors qu'il aurait fallu le sortir une grosse demi-heure, qu'il ait l'occasion de se vider correctement la vessie

Tu croiras donc avoir corrigé le problème, mais tu peux avoir la certitude que, tot ou tard, tu sera de nouveau confronté à un problème similaire (le chien qui pisse sur le tapis persan), simplement parce que l'ordre des actions est différent.

Maintenant, imaginons que l'on crée une fonction qui ne s'occupe que de faire le café, une autre qui ne s'occupe que de faire la vaisselle, une troisième qui ne s'occupe que de faire la lessive, une quatrième qui ne s'occupe que de sortir le chien et une cinquième qui ne s'occupe que d'aller faire les courses.

Les 120 combinaisons possibles des fonctions "complexes" peuvent être implémentées très facilement en modifiant l'ordre dans lequel ces différentes fonctions sont appelées. Et, si tu reçois un rapport de bug disant que le chien pisse sur le tapis persan du client, tu n'en a rien à foutre de savoir l'ordre dans lequel les différentes actions sont prises : c'est parce que tu ne promène pas le chien pendant assez longtemps.

Tu augmente donc le temps de la ballade et tu as la garantie (pour autant que cela ait effectivement permis de résoudre le problème) que le problème est résolu pour les 120 combinaisons possibles, et que le chien ne pissera plus jamais à l'intérieur.

l’expérience d'un joueur évolue tout au long d'un jeu, en fonction de l’expérience, le niveau du joueur augmente. les deux sont donc lié... plutôt que de faire deux fonction, je l'ai réduite à une seule. je pensais que c'était une bonne chose.

Non, et je viens de t'expliquer pourquoi (par contre, il n'est pas exclu que tu aies une fonction qui augmente l'expérience du joueur et qui, lorsque l'on atteint un certain nombre de point d'expériences, décide d'appeler la fonction qui s'occupe d'augmenter le niveau )

quel est le réel problème de cette fonction à deux utilités?

Dans le cas bien particulier que tu cite, pour être tout à fait honnête : aucun.

Dans le cas général, pose toi simplement une seule question : Et Si...?

Et si on voulait changer l'ordre dans lequel sont faites les deux choses?

ou pire

Et si on voulait une nouvelle fonction inversant l'ordre dans lequel les deux choses sont faites, tout en gardant la première version?

ou encore

Et si j'accèpte q'une fonction ait deux utilités, ne vais-je pas avoir tendance d'en accepter une qui en a 3, 4, 5... 10...100? quelle sera la limite?

pourquoi l'entrée ne serait elle pas telle qu'attendue ?

Parce que l'utilisateur est -- au mieux -- un imbécile distrait, au pire, quelqu'un qui cherche à accéder à un niveau de contrôle auquel il ne devrait pas avoir accès

pour le point 2., je t'avoue ne pas avoir trop compris :p

"prends l'habitude, dès maintenant, d'écrire std::cout, std::vector, std::string, etc." et je dois noter cela pour chaque type de variable utilisé?

Pour tout ce qui est issu de la SL (la bibliothèque standard), en tout cas, oui.

PS: peut-être mon livre (lien en signature) te permettra-t-il d'améliorer encore la manière dont tu écris ton code (et ta conception de manière générale)

[francois1990]

donc je prend note : il est plus intéressant de créer des fonctions qui ne s'occupe que d'une chose

std::cout, std::vector, std::string, etc ... je dois placer tout ca ou ?

Pour la question, j'utilise code::blocks
oui ce serai cool d'avoir un rapport du logiciel lorsqu'il trouve des choses bizarres

[koala01]

donc je prend note : il est plus intéressant de créer des fonctions qui ne s'occupe que d'une chose

Ouaip

std::cout, std::vector, std::string, etc ... je dois placer tout ca ou ?

Là où tu en as besoin, par exemple :
au lieu d'écrire le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <string>
using namespace std;
int main(){
    string str{"Hello world"};
    /* ... */
}

tu écriras le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#include <string>
int main(){
    std::string str{"Hello world"};
    /* ... */
}

au lieu d'écrire le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <iostream>
using namespace std;
int main(){
    cout<<"I'm happy";
    /* ... */
}

tu écriras le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <iostream>
 
int main(){
    std::cout<<"I'm happy";
    /* ... */
}

et ainsi de suite