Noms des classes

[Arcalys]

Me revoici,

Je ne savais pas où poster ceci, car cela ne vaut pas que pour C++, alors désolé si je ne suis pas dans la bonne section

J'aurais voulu quelques conseils sur "Quels noms donner à mes classes?"

Est ce que vous me conseillez d'utiliser un préfixe ou suffixe a chaque classe ou quelque chose de ce style? Les noms en français ou anglais? Enfin, des petits détails que je trouve très importants lorsque quelqu'un doit rentrer dans l'un de mes programmes


Merci d'avance

[Duaran]

Déjà pour la langue, l'important n'est pas que ce soit l'anglais ou le français, mais que ce soit toujours la même (moi je suis même pas cette règle ... trop la flemme d'avoir des noms à ralonge .

Duarna

[MrCool]

Personnellement, je préfère tout faire en anglais de manière à garder une certaine uniformité (les bibliothèques que tu vas utiliser seront sans aucun doute en anglais, donc...).

Et en CamelCase (ie: JeSuisUneVariable et pas je_suis_une_variable).

Sinon la règle la plus importante est de garder des noms EXPLICITES.
Ie: nommer MyBigGameElement MBGG va te faire aller dans le mur parce que ton projet ne sera absolument pas maintenable.

Pour éviter des noms trop long, il y a de toutes façons des façons simples d'y arriver au travers des namespaces.

Au lieu de faire: MyIAGameElement, l'approche plus agréable serait: game::ia::MyElement.
L'imbrication des namespaces fait que si tu es déjà dans le namespace, tu n'as pas besoin de re-préciser où tu te trouves... (MyElement suffit).


Pour étendre un peu le débat, la question est quelle coding style utiliser?

Il y a quelques exemples ici:
http://www.chris-lott.org/resources/cstyle/
http://www.blender.org/documentation...tyleguide.html

Evidemment, la Gnu Coding Standard:
http://www.gnu.org/prep/standards/

(elle est beaucoup plus sur l'architecture et l'organisation d'un projet en lui-même, mais de nombreux conseils donnés son fondamentaux comme la façon de sortir une erreur sous Linux).

De manière générale, la seule coding style que je trouve totalement insupportable c'est la notation hongroise:
http://fr.wikipedia.org/wiki/Notation_hongroise

Heureusement, depuis .net, son plus fervent supporter (Microsoft) a retourné sa veste et ne l'utilise plus (ouf!).

[Arcalys]

Merci de la réponse

Je vais aller jeter un oeil à tout cela

Edit: Une question qui n'a rien a voir avec les noms. Est-il préférable de ne mettre qu'une seule classe par header? Ou plusieurs classes peuvent être regroupées? (En imaginant que par exemple le fichier soit IA.h et qu'on ait plusieurs classes intervenant pour l'IA)

[blaster]

Excellent conseil de MrCool, je rajouterai même qu'il s'applique également pour les noms de variables.

A eviter absolument les char c, int tmp, String s, etc etc surtout si le code est destiné à être éventuellement lu par quelqu'un d'autre.

Concernant ta question sur les headers je pense que c'est techniquement possible mais je le deconseillerai, quitte à avoir plusieurs classes IA autant les regrouper dans un package

[Mokona]

Posté par MrCool

De manière générale, la seule coding style que je trouve totalement insupportable c'est la notation hongroise:
http://fr.wikipedia.org/wiki/Notation_hongroise

Heureusement, depuis .net, son plus fervent supporter (Microsoft) a retourné sa veste et ne l'utilise plus (ouf!).

Pour avoir fait des projets de grandes envergures pro avec et d'autres sans notation hongroise, mon avis est différent :

- la notation complète hongroise telle que Microsoft l'utilisait était ridicule, comportait trop d'informations jusqu'à noyer le nom de la variable ;
- le retournement de veste de Microsoft est tout aussi ridicule, passant dans l'extrême inverse et perdant les énormes bénéfices d'une telle notation, si elle est "contrôlée".

Le deuxième point est encore plus ridicule si l'on considère que, tout en bannissant les préfixages en les taxant de tous les maux de la Terre, Microsoft continue à préfixer certaines choses (les I d'interface par exemple).

J'ai un article complet là-dessus à terminer, faudra que je pense à m'y remettre.

Pour répondre à la question initiale sur les classes, un CamelCase est recevable (et même trèsutilisé). Inutile d'un C devant.

Pour ce qui est des namespace remplaçant complètement des préfixages par packages, John Lakos dans son excellent Large Scale C++ Design émet une réserve. Et même si le livre a 10 ans et que les namespace étaient encore balbutiant, la remarque est recevable. Maintenant, le bouquin parle de "Large Scale", ce qui n'est probablement pas le cas d'Arcalys.

(il y a peu, je suis tombé sur un conflit de noms dans une API entre deux classes de namespace différent, ces namespace étant, par design, souvent utilisées ensemble. Du coup, la syntaxe à l'utilisation s'en trouve très alourdie et les erreurs plus facile à faire).

[MrCool]

Edit: Une question qui n'a rien a voir avec les noms. Est-il préférable de ne mettre qu'une seule classe par header? Ou plusieurs classes peuvent être regroupées? (En imaginant que par exemple le fichier soit IA.h et qu'on ait plusieurs classes intervenant pour l'IA)

Non, une classe par header est IMHO le mieux.

Evidemment, on peut trouver quelques exceptions comme des classes imbriquées utilisées en interne:

class A
{
public:
  enum B { /*FIXME*/ }; // Un enum utilisé par A

private:
  class C
  {
  };

  // J'utilise B dans mes méthodes privées...
};

Autre variante sans classe imbriquée:

namespace Foo
{
  // Un namespace non-nommé a la propriété intéressante de n'être
  // accessible que par les classes du namespace parent (ici Foo).
  namespace
  {
     class B
     {
     };
  };

   class A
   {
     // B est une classe utilisée en interne.
   };

Dans ces deux cas, plusieurs classes par header peut être justifié.

Par contre, dans les autres cas, il vaut bien mieux avoir un header par classe.

Si tu souhaites regrouper des classes, les namespace servent à ça. En général, on regroupe même toutes ces classes qui sont du même namespace dans un répertoire à part.

Exemple: src/ia va contenir toutes les classes qui servent pour l'IA et qui seront toutes dans le namespace IA.

Un bon découpage du projet peut mener à avoir énormément de fichiers sources, ce n'est vraiment pas un problème.

[Mokona]

Si tu souhaites regrouper des classes, les namespace servent à ça. En général, on regroupe même toutes ces classes qui sont du même namespace dans un répertoire à part.

Il s'agit là d'architecture physique. C'est un sujet trop souvent mis de côté, ou même complètement ignoré. Il faut en effet insister là-dessus : l'organisation des fichiers sur le disque est toute aussi importante que l'architecture logicielle.

Les manières de faire forment un large sujet, celle proposée par MrCool est un bon premier pas.

Un bon découpage du projet peut mener à avoir énormément de fichiers sources, ce n'est vraiment pas un problème.

Toujours de l'architecture physique. Encore faut-il détailler pourquoi ce n'est pas un problème. C'est une bonne chose car garder des fichiers courts augmente la lisibilité. Mais augmenter le nombre de fichiers peut aussi faire exploser les temps de compilation.

Là encore, je renvois au Lakos, qui est un bon livre de référence pour éviter certains pièges.

[Whirly]

Tant qu'à conseiller des bouquins de base pour l'écriture de code un de mes favoris reste "Code Complete", qui fait le tour des principes de base pour programmer.

[Aranoth]

Très intéressant comme sujet, ça sort un peu de l'ordinaire.

J'ai personnellement un problème : c'est la taille à rallonge de mes fichiers cpp, la lisibilité du code en prend un coup.

En fait je pense que le problème vient de mes classes qui sont légèrement obèses. Le pire exemple devant être ma classe GameManager.

Existe t-il un remède pour ça ? Séparer l'implémentation d'une classe dans plusieurs fichiers ne me semble pas être une bonne solution.
Faut-il que je découpe plus mon code, par exemple en créant des classes plus petites chargées d'une seule et unique tâche pour alléger ces managers (exemple : actuellement, c'est le GameManager lui même qui s'occupe de gérer les états, dois-je passer par un StateManager ? Pour les "règles" de mon jeu, tout cet aspect "gameplay", dois-je aussi sous-traiter ?)

Bref, quelques questions qui sortent un peu de l'aspect purement "technique" de la programmation

[MrCool]

Toujours de l'architecture physique. Encore faut-il détailler pourquoi ce n'est pas un problème. C'est une bonne chose car garder des fichiers courts augmente la lisibilité. Mais augmenter le nombre de fichiers peut aussi faire exploser les temps de compilation.

Tout à fait, mais si l'on respecte ce type de règle, on se retrouve avec une architecture modulaire où l'on peut aisément avoir un module (ou namespace ou répertoire...) une bibliothèque statique.

Les "convenience libraries" des Autotools sont notamment là pour ça sous Linux.

Mais même dans ce cas, le couplage entre les modules reste un gros problème.

Existe t-il un remède pour ça ? Séparer l'implémentation d'une classe dans plusieurs fichiers ne me semble pas être une bonne solution.
Faut-il que je découpe plus mon code, par exemple en créant des classes plus petites chargées d'une seule et unique tâche pour alléger ces managers (exemple : actuellement, c'est le GameManager lui même qui s'occupe de gérer les états, dois-je passer par un StateManager ? Pour les "règles" de mon jeu, tout cet aspect "gameplay", dois-je aussi sous-traiter ?)

Je ne sais pas exactement ce que gère ton "GameManager", mais il est certain qu'une classe ne devrait jamais être une poubelle où l'on mets tout ce qui ne rentre pas ailleurs (antipattern object divin => http://fr.wikipedia.org/wiki/Antipat....27objet_divin).

D'autre part, le découpage en sous-méthode (privée si nécessaire) est crucial.

Difficile d'établir une limite, mais disons que 50 lignes par méthode c'est bien, 100 ça commence à faire et plus de 300 c'est trop.

(pour le coup c'est vraiment une estimation et ça dépends de beaucoup de facteurs, mais ça donne une idée générale)

[Mokona]

Posté par Aranoth

Existe t-il un remède pour ça ? Séparer l'implémentation d'une classe dans plusieurs fichiers ne me semble pas être une bonne solution.

En effet, mauvaise solution. Même en partant du principe malheureusement en vogue actuellement qui consiste à dire : peu importe, on a des IDE mega balaise avec des plugins pour se balader dans le code (pas que ça soit pas utile, au contraire, mais ce n'est pas une excuse pour faire n'importe quoi).

Il n'y a pas de remède universel, mais un bon début de méthode est, pour chacune de test classes, de faire la liste de ses responsabilités. Si cette liste dépasse quelques entrées, c'est qu'il y a peut-être un soucis, et qu'il convient de déléguer.

Comme MrCool, je ne connais pas le contenu de ton manager. Mais si ses responsabilités sont de s'occuper de toute la gestion du jeu, alors il est possible de diviser les différentes parties à manager pour laisser au game manager la seule responsabilité : appeler les différents managers.

La division, bien sûr, demande de la reflexion.

[Aranoth]

Je ne sais pas exactement ce que gère ton "GameManager", mais il est certain qu'une classe ne devrait jamais être une poubelle où l'on mets tout ce qui ne rentre pas ailleurs (antipattern object divin => http://fr.wikipedia.org/wiki/Antipat...27objet_divin).

Je ne connaissais pas cette dénomination, "anti-pattern" ^^
En effet, mes managers ressemblent bien à des objets divins...

Difficile d'établir une limite, mais disons que 50 lignes par méthode c'est bien, 100 ça commence à faire et plus de 300 c'est trop.

Je n'ai pas de méthode excédant les 50 lignes, le problème est que j'ai beaucoup de méthodes dans la même classe, et y accéder est difficile (j'utilise l'IDE Code::Blocks qui est moins avancé (et foutoir, à mon sens) que Visual C++).

Comme MrCool, je ne connais pas le contenu de ton manager. Mais si ses responsabilités sont de s'occuper de toute la gestion du jeu, alors il est possible de diviser les différentes parties à manager pour laisser au game manager la seule responsabilité : appeler les différents managers.

En effet, je penses que je vais faire comme ça. Je viens de jeter un coup d'oeil à mon GraphicManager (ce que j'évite de faire en temps normal, la faute à la construction type "lasagne"... les couches basses sont pas jolies jolies) et je me rends compte qu'il s'occupe du GUI, alors que ça ne devrait pas être à lui de le faire.

Merci pour vos conseils

[Mokona]

Posté par Aranoth

(j'utilise l'IDE Code::Blocks qui est moins avancé (et foutoir, à mon sens) que Visual C++).

Je te rassure : j'ai déjà travaillé sur de gros projets mal construits avec Visual C++ et ce ne sont pas les facilités d'édition qui peuvent compenser quoi que ce soit.