jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Derniers journaux de ginkyo :

[15/09@20:48] Simple essai de regex sur un quelques extraits linuxfr
[27/06@13:31] Applis de gestion de pannes en mode gestion devis
[06/04@13:16] Conversion de code vb.net vers C# gratuit pour projet libre
[16/10@19:09] Réflexion sur le format OASIS opendocument et la séparation forme/fond
[24/08@12:22] Étiquetage de photos avec IPTC XMP
[27/02@00:08] Du bon usage de la traduction
[07/09@09:18] banque de données libre d'audiotextes au format real
[20/04@15:02] Tutoriel succinct mis en GNU Arch
[03/02@15:44] 20 ans de GNU et RIEN dans GNU/LinuxMag
[12/01@13:26] Sortie du noyau Linux 2.6.1 et MODÉRATION
[20/12@17:43] Le logiciel poste à poste Kazaa légalisé au PaysBas !
[15/12@23:46] Sortie de SCO UnixWare® 7.1.3
[22/08@13:54] Mini souris optique sans fil Cellink OPM-602
[08/07@08:45] Le centre URSSAF du Sud-Ouest déploie ses services de télé-déclaration en environnement Open Source
[25/06@07:19] Arguments POUR le C
[10/06@06:04] Liste de collecticiels (groupware in english)
[07/05@12:17] Recherche distrib linux néophyte pour P200 à 64moRAM
[25/02@16:00] Discussion avec canon [pilote GNU/linux][imprimante i850]
[25/02@15:51] Discussion avec canon [pilote GNU/linux][imprimante i850]
[22/02@00:01] Ordi portatifs avec Lindows à 800$ !

Journal : Convention de nommage code et Bdd

Posté par ginkyo (page perso, ) le 05 janvier 2007

Bonjour,
Je viens vers vous pour récolter quelques expériences de votre part :)
En effet, j'aimerais avoir vos préférences pour le nommage des
- classes
- méthodes ou fonctions
(pê aussi méthodes constructeurs /destructeurs/accesseurs/manipulateurs, héritées)
- champs ou variables

Mettez-vous des str_ma_variable, m_MavariableMembre_string, int_i, Maclasse, maMéthode, chaine_bidule, etc... ?

Et pour vos Bdd :
lib_nom ou nom, ou txt_nom pour un champ varchar,
id, ou id_nom ou num_nom, pour l'identifiant de la table nom
t_table pour une table
TJ_table pour une table en jointure
etc...

Et pour vos formulaires :
chkb_entreprise pour les cases à cocher

Mais tout simplement en nous donnant quelques liens de conventions de nommages utiles, strictes, homogènes, utilisables.

Autrement auriez-vous quelques liens vers des codes sources de projets exemplaires sur ces caractéristiques ?

En vous remerciant

Un seul lien pour le sql :
http://sql.developpez.com/standards/

> Lire le journal (36 commentaires, moyenne: 3,5).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Notation hongroise

Posté par jjl (page perso, ) le 05/01/2007 à 10:45. (lien). Évalué à 2.

Chez nous pour faire du C on utilise une variante de la notation hongroise
http://en.wikipedia.org/wiki/Hungarian_notation

En plus on prefixe par une lettre representant ce qu'est le nom de variable (ou fonction) : variable externe, globale, fonction, paramètre...

Par exemple E_u8Cpt sera un compteur entier non signé sur 8 bits (u8) déclaré à l'exterieur du fichier courant (E_)
F_pasBuffers sera une variable locale (F_) pointeur (p) sur un tableau (a) de structures (s)

Cela semble un peu compliqué à la lecture mais une fois que tu as bien en tête la notation, ca simplifie énormément la comprehension du code surtout si vous êtes plusieurs à travailler sur le même.

Après il faut adapter la notation aux besoins du projet, tout le monde n'a par exemple pas besoin de differencier les u8, u16 ou u32

[^]Re: Notation hongroise

Posté par Vincent Richard (page perso, ) le 05/01/2007 à 11:14. (lien). Évalué à 6.
Et ensuite, que se passe-t-il quand tu veux changer le type d'une variable ? ;-)
- [^]Re: Notation hongroise
  
  Posté par achil () le 05/01/2007 à 11:52. (lien). Évalué à 1.
  Tu utilises les fonctions de remplacement de ton editeur de code?
  
  Bon il est important tout de même de ne pas trop modifier ce qui est hors de la fonction dans laquelle tu changes le nom de ta variable.
  Il vaut mieux préférer la méthode du suivant, que du "remplacer tout". :)

[^]Re: Notation hongroise

Posté par Krunch (Jabber id, page perso, ) le 05/01/2007 à 11:21. (lien). Évalué à 10.
C'est un mauvais usage de la notation hongroise. Le préfixe doit refléter l'usage qu'on fait de la variable et non son type (à moins d'être un typedefeur pathologique).
http://www.joelonsoftware.com/articles/Wrong.html

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

[^]Re: Notation hongroise

Posté par Laurent J (page perso, ) le 05/01/2007 à 12:48. (lien). Évalué à 9.
personnellement, je trouve ta notation vraiment trop horrible et surtout beaucoup trop compliqué.

Et je ne suis pas sûr que ça m'avancera plus. Là dans ton exemple, c'est un pointeur sur tableau de structure. Mais structure de quoi ? Paf, t'es obligé de chercher dans les sources la déclaration de ladite structure (et bien sûr avant, la declaration de la variable proprement dite pour savoir quelle est le nom de la structure). Donc finalement ça ne résout pas le problème (celui de comprendre tout de suite le type).

Et pire, dans ton exemple, il y a redondance d'information dans le nom. Si ta variable s'appelle un buffer, on s'attend forcément à une structure ou à un tableau (à priori, tout informaticien sait ce qu'est un buffer). Donc inutile de le préciser dans ton préfixe. en plus, s'agissant d'un pointeur, on va principalement l'utiliser en préfixant par une * à l'usage, donc rien qu'avec ce *, on sait qu'il s'agit d'un pointeur...

Vaut mieux un nom bien plus explicite. Ici tu dis que c'est un buffer. Mais buffer de quoi ? de carottes ? d'octets ? de paquet tcp ? je trouve qu'un nom comme bufferTcp c'est bien plus parlant.

Donc finalement F_pasBuffer ne veut absolument rien dire, surtout pour le type qui débarque dans le projet. (oui je sais, tu vas me dire, c'était juste un exemple, mais finalement, il montre bien les incohérences et pièges de ta notation).

Un bon code source devrait pouvoir se lire le plus naturellement parlant, quitte à avoir des noms longs (ce qui n'est pas un problème grâce à la complétion automatique de code dans les éditeurs)

entre
if( (*F_pasBuffer)[0].M_u8sourcePort == 80)...
et
if( (*bufferTcp)[0].sourcePort == 80)...

y a pas photo, je prend le deuxième...

[^]Re: Notation hongroise

Posté par André Rodier (page perso, ) le 05/01/2007 à 13:04. (lien). Évalué à 3.

Cela semble un peu compliqué à la lecture mais une fois que tu as bien en tête la notation, ca simplifie énormément la comprehension du code surtout si vous êtes plusieurs à travailler sur le même.

Si vous êtes plusieurs a travailler sur le même fichier, n'y aurait-il pas un léger problème de séparation des fonctionnalités ?
Ou comment on mettre un pansement sur une jambe de bois...

[^]Re: Notation hongroise, variation sur Coluche

Posté par André Rodier (page perso, ) le 05/01/2007 à 16:00. (lien). Évalué à 9.
Le codage hongrois, hongrois qu'on code, mais on code pas...
- [^]Re: Notation hongroise, variation sur Coluche
  
  Posté par ola () le 05/01/2007 à 16:08. (lien). Évalué à 7.
  ouaip.
  
  et quand le management l'apprend, hongrie au scandale.

liens

Posté par Krunch (Jabber id, page perso, ) le 05/01/2007 à 11:17. (lien). Évalué à 8.

http://www.clifford.at/style.html
http://www.joelonsoftware.com/articles/Wrong.html
http://www.laas.fr/~matthieu/cours/c-superflu/
http://www.gnu.org/prep/standards/standards.html
http://lxr.linux.no/source/Documentation/CodingStyle (ironiquement le nom du fichier est en MixedCase)
http://www.montefiore.ulg.ac.be/~piater/courses/Coding-Style(...)
http://www.run.montefiore.ulg.ac.be/~martin/resources/kung-f(...)

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

[^]Re: liens

Posté par qbeek_back (page perso, ) le 05/01/2007 à 11:24. (lien). Évalué à 1.
++

Les deux premiers sont vraiment très bons. Merci.

[^]Re: liens

Posté par jraf () le 05/01/2007 à 13:04. (lien). Évalué à 1.
pour le java
https://jjguidelines.dev.java.net/book/html/ch01.html

Petits avis ans importance

Posté par André Rodier (page perso, ) le 05/01/2007 à 11:31. (lien). Évalué à 8.

Perso :

J'utilise les mêmes conventions pour les variables locales, les paramètres de fonctions ou de méthodes, et les variables membres de classe. En effet, ces variables peuvent très bien être échangées au cours du développement du programme.

De ce fait, je trouve les conventions de préfixage conseillées dans certaines documentations, en particulier les MFC, dangereuses :
Je ne préfixe pas mes membres de classe avec m_

Je ne préfixe pas non plus mes noms de variables avec un type, bien que facile, c'est une mauvaise solution a une question récurrente du programmeur : comment vais-je appeler cette variable ?

J'évite donc les variables du style nLock, ou strUserAgent, d'ailleurs foisonnantes dans le code source des MFC.

Pourquoi ? Parce-que si vous décidez de changer le type d'une variable, soit vous devez renommer la variable partout ou elle est utilisée, soit vous avez une hérésie dans votre convention de nommage.

Lorsque je choisis un nom de variable, je me pose les questions du style : a quoi va servir cette variable, que va-t-elle représenter, etc... C'est mieux pour la personne qui va relire le programme.

Du coup, mes variables locales, mes membres de classe, et mes paramètres s'appellent, par exemple :
userAgent, lastUserChoice, locked, etc
Elles commencent toutes par une minuscule.

Pour les variables globales, j'utilise une majuscule pour la première lettre :

SystemVersion, UserAgent, ...

J'utilise généralement l'anglais pour mon code, parce que les noms sont souvent plus courts, et aussi parce que c'est une langue assez connue dans le monde, qui de plus ne nécessite pas d'accents...
Désolé pour les anglophobes...

Pour les constantes, j'utilise une convention style C :

SYSTEM_VERSION, USER_AGENT, ...

Je sais, c'est très laid, mais cela a l'avantage de décourager le programmeur à trop les utiliser.

En C, on avait des #define plein les fichiers, en C++ et dans d'autres langages modernes, vous avez des constantes statiques de classe, les namespace, etc...

J'évite aussi les redondances :

Ex:
Je n'écris pas : Enum Color { colorRed, ColorYellow, ColorBlack, ...}
mais plutôt : Enum Color { red, yellow, black, ...}

a auivre ...

[^]Re: Petits avis ans importance

Posté par GuieA_7 (page perso, ) le 05/01/2007 à 12:21. (lien). Évalué à 2.
Tes remarques sont plutôt pertinentes.

Il n'y a que pour le coup des préfixes aux variables membres où je pense que c'est une bonne chose (mais je préconise un '_' tout simple, pas un 'm_', et seulement pour les attributs privés). En C++, ça évite de faire un this->member, plus propre mais parfois un peu trop verbeux. Dans les langages sans encapsulation (comme python), ça indique bien les membres 'privés'.

Sinon pour le codage en anglais, je pense que c'est le contraire (coder en français dans notre cas) qui est une hérésie. Franchement entre coder en anglais et maîtriser l'anglais, il y a une marge suffisante pour qu'un gros mauvais en anglais comme moi puisse puisse quand même coder en anglais. Rien qu'avec le jargon informatique de base (file, array, buffer, pointer....) et quelques termes très courants (value, count, first, add...) je pense qu'on peut faire 90% du code de tous les jours. Pour être déjà tombé sur du code en polonais, et bien j'aurais préféré un mauvais anglais que du polonais même très bon !! Dans le logiciel libre, c'est d'autant plus vrai je pense.
- [^]Re: Petits avis ans importance
  
  Posté par Nicolas (page perso, ) le 05/01/2007 à 13:33. (lien). Évalué à 2.
  Il me semble que le préfixe "_" est réservé au C++. Je n'ai pas de pointeur pour confirmer ça, mais c'est à vérifier.
  Le double underscore est utilisé pour les extensions aux C++ ISO il me semble, peut-être une des raisons du pourquoi...
  
  Maintenant, je dis peut-être n'importe quoi, à vérifier.
  - [^]Re: Petits avis ans importance
    
    Posté par Troy McClure (page perso, ) le 05/01/2007 à 17:04. (lien). Évalué à 2.
    Je ne suis pas un pointeur mais je confirme. Si tu commences à nommer des variables ou autres _A, _B, etc tu t'exposes à quelques surprises parce qu'elles sont reservée à l'usage du compilateur et des entetes de l'os (sous irix par exemple, il y a quelque part un #define _A qui m'avait bien fait tourner en bourrique :)
    - [^]Re: Petits avis ans importance
      
      Posté par GuieA_7 (page perso, ) le 05/01/2007 à 18:15. (lien). Évalué à 1.
      Je veux bien te croire ; pourtant '_member' et 'm_member' sont des classiques il me semble (ce qui ne veut pas dire que ça ne soit pas une erreur). Autant je savais pour les '__' (genre __FILE__), autant là je ne savais pas ; faut dire qu'après quelques milliers de lignes de C++, je n'ai jamais eu de problème à cause ça (mais des tas d'autres raisons !)....
      
      D'un autre côté, une variable 'A' ou '_A', c'est de la merde dans les 2 cas.... :)
      - [^]Re: Petits avis ans importance
        
        Posté par Troy McClure (page perso, ) le 05/01/2007 à 19:01. (lien). Évalué à 2.
        > D'un autre côté, une variable 'A' ou '_A', c'est de la merde dans les 2 cas.... :)
        
        Absolument pas, ça ne t'arrive jamais de nommer une variable 'i' pour un compteur de boucle, ou 'A','x' et 'B' pour la matrice, l'inconnue et le second membre d'un système linéaire ? Il y a des situations où ces noms courts sont parfaitement explicites.
        
        Sinon la regle exacte est un peu plus velue que ce dont je me souvenais:
        
        Identifiers with two initial underscores or an initial underscore followed by an uppercase letter are reserved globally for use by the compiler.
        
        C Identifiers that begin with a single underscore are reserved as identifiers with file scope in both the ordinary and tag namespaces.
        
        C++ Identifiers that begin with a single underscore are reserved in the global namespace.
        
        http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/top(...)
        
        [^]Re: Petits avis ans importance
        
        Posté par GuieA_7 (page perso, ) le 07/01/2007 à 14:53. (lien). Évalué à 1.
        OK, merci du renseignement (et de t'être farci la recherche).
        
        Et oui tu as raison, les variables à une lettre (sans compter i, j, k pour les compteurs) ça peut être utile, mais sorti du cadre des maths (ou associé), vaut mieux éviter (tu avais vu le smiley non ?).

[^]Re: Petits avis ans importance

Posté par Matthieu MARC () le 05/01/2007 à 12:53. (lien). Évalué à 2.
Nom des fonctions :
j'essaye de les faire commencer par le nom du fichier dans lequel elles sont écrites (ou le nom du module) pour pouvoir les retrouver plus facilement

Variables :
globale : en majuscule commençant par _ ( _TOTO)
paramètre d'une fonction : commençant par _ pour les distinguer des variables de la fonction (_param)

Sinon rien de bien important.
- [^]Re: Petits avis ans importance
  
  Posté par rb14 () le 05/01/2007 à 23:46. (lien). Évalué à 0.
  > globale : en majuscule commençant par _ ( _TOTO)
  
  Trop dangeureux! Plus le soft est gros, plus TOTO a de fortes chance d'être déjà utilisé! (régle vérifié au boulot, et ses amis TITI, TUTU et cie aussi)

facile

Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 05/01/2007 à 12:08. (lien). Évalué à 3.

Pour ne pas trop se poser de question, il suffit de faire un truc du style
echo -n $RANDOM | md5sum | tr 1234567890 ghijklmnop
et de prendre ce qui suis comme nom de variable. Comme ça, pas besoin de se casser la tête une demi-heure à comprendr pourquoi la variable a ce nom, vu qu'il n'y a pas de raison.

--
[ Répondre ] Ce commentaire est-il impertinent ou utile ?

[^]Re: facile

Posté par André Rodier (page perso, ) le 05/01/2007 à 12:12. (lien). Évalué à 10.
ou alors, pour un programme sans importance :

char dassaut ;
int erdit ;
short adidas ;
...
- [^]Re: facile
  
  Posté par Clément Schreiner (page perso, ) le 05/01/2007 à 13:59. (lien). Évalué à 5.
  static electricity;
- [^]Re: facile
  
  Posté par Julien Duponchelle (page perso, ) le 06/01/2007 à 03:10. (lien). Évalué à 1.
  float aison;

[^]Re: facile

Posté par Krunch (Jabber id, page perso, ) le 05/01/2007 à 13:55. (lien). Évalué à 2.
À noter que C99 impose que les « identifiants externes » puissent se distinguer selon leurs 31 premiers caractères. Un md5 en héxa c'est 32 chars. D'un autre côté faut vraiment pas avoir de bol pour tomber sur une collision sur les 120 premiers bits.

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

Mozilla

Posté par Laurent J (page perso, ) le 05/01/2007 à 12:16. (lien). Évalué à 3.

Notation utilisé dans mozilla (C++) :

Les noms sont composés de mot accolés dont la première lettre est en majuscule, sauf la première (exception : les noms de méthodes c++ et je ne sais plus pourquoi )

Et il y a un préfixe :

- g pour les variables globales
- a pour les noms d'arguments
- m pour les propriétés de classe
- rien pour les variables locales
- les noms de classes sont préfixés par deux ou trois lettres qui identifie l'auteur (typiquement "ns" pour netscape, et on commence à voir apparaire des "moz") ex : nsDocument
- les noms d'interfaces contiennent un I aprés le prefixe. ex : nsIDocument

Pas de préfixe indiquant le type. De toute façon, de nos jours où on utilise majoritairement des langages à objets, je trouve incohérent d'utiliser des préfixes de type. Si on utilise str pour les chaines, pourquoi ne pas utiliser préfixer les noms par les noms de classe ? ex : nsDocumentFoo pour indiquer que la variable est un objet de type nsDocument. On le fait pas parce que c'est source de confusion. CQFD.

[^]wtf

Posté par Krunch (Jabber id, page perso, ) le 05/01/2007 à 12:46. (lien). Évalué à 2.
http://www.mozilla.org/hacking/mozilla-style-guide.html#Gene(...)
Don't use NULL for pointers.

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
- [^]Re: wtf
  
  Posté par Laurent J (page perso, ) le 05/01/2007 à 12:50. (lien). Évalué à 2.
  et donc ?
  - [^]Re: wtf
    
    Posté par Krunch (Jabber id, page perso, ) le 05/01/2007 à 13:33. (lien). Évalué à 3.
    NULL est définit expressément pour être attribué et comparé à des pointeurs. Ca semble idiot de s'en passer. Éviter les warnings pour éviter les warnings (surtout s'ils sont causés par une bibliothèque externe pourrie) ne sert à rien (si ce n'est à cacher les défauts de la dite bibliothèque).
    
    --
    Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
    pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
    - [^]Re: wtf
      
      Posté par Gof (Jabber id, page perso, ) le 05/01/2007 à 13:51. (lien). Évalué à 2.
      Pas en C++
      
      il y a 0 pour ça
      (bien que j'utilise souvent 0L, mais c'est juste une convention)
      - [^]Re: wtf
        
        Posté par Sebastien Binet () le 05/01/2007 à 14:13. (lien). Évalué à 1.
        Et pour C++0x, il y a(ura) le nouveau mot reserve null_ptr ou nullptr
    - [^]Re: wtf
      
      Posté par Laurent J (page perso, ) le 05/01/2007 à 14:23. (lien). Évalué à 3.
      Ce document a plus de 5 ans. Depuis, les compilateurs ont évolués, et il est probable que cette recommandation soit obsolète avec les compilateurs récents. (note : conçernant le sous lien http://www.mozilla.org/hacking/portable-cpp.html , il est devenu carrement obsolète puisque les compilateurs modernes implementent maintenant mieux les exceptions et autres trucs spécifiques C++, et donc dans Mozilla 2, ils vont enfin passer à ces choses "modernes"...)
      
      Donc à l'époque, si ils ont marqués qu'il fallait éviter d'utiliser NULL, c'est qu'il fallait éviter d'utiliser NULL.
      
      Et franchement, se payer des milliers de warning à cause de l'utilisation de NULL, je trouve ça pas top et inutile. Autant donc l'éviter. (n'oublie pas que le code source de mozilla, c'est quelques millions de lignes de code et que ça doit compiler sur un maximum de plateforme...)

Bah heu...

Posté par Wawet76 (page perso, ) le 05/01/2007 à 15:43. (lien). Évalué à 3.

foo, bar, baz, toto, titi, tata, ma_variable, maFonction, plop, coin, tralala...

C'est pas les idées qui manquent.

[^]Re: Bah heu...

Posté par d-jo (page perso, ) le 06/01/2007 à 07:10. (lien). Évalué à 3.
i , s ,i2, s2, j, k, l ...

[^]Re: Bah heu...

Posté par Jean-Philippe (page perso, ) le 06/01/2007 à 13:45. (lien). Évalué à 3.
Perso c'est bob, bib bub, bab....

y'a pas 1 seule solution

Posté par TImaniac (page perso, ) le 05/01/2007 à 15:44. (lien). Évalué à 3.

Pour le code :
S'il y a des guidelines spécifiques pour le projet auquel tu participes, respecte les.
Sinon s'il y a des guidelines spécifiques pour la plateformes de dev que tu utilises, respecte les.
Sinon essaie de respecter les conventions de codage les plus répendues sur la plateformes que tu utilises.
Sinon fait ce que tu veux du moment que tu respectes tes propres conventions :) (exception : fais ce que tu veux au niveau de la syntaxe, mais par pitié toujours avoir un nom cohérent)
Tout ca pour dire qu'il faut mieux être un mouton dans ce domaine et faire comme le maximum de personne. Pourquoi ? Parcque ton code sera peut être (espérons) relus un jour, et c'est toujours mieux d'avoir une syntaxe commune avec les autres developpeurs.
A noter qu'il existe des outils pour vérifier sur certaines plateformes le bon respect des conventions de nommage.

--
MonoFrance

Revenir en haut de page

Journal : Convention de nommage code et Bdd

Notation hongroise

[^]Re: Notation hongroise

[^]Re: Notation hongroise

[^]Re: Notation hongroise

[^]Re: Notation hongroise

[^]Re: Notation hongroise

[^]Re: Notation hongroise, variation sur Coluche

[^]Re: Notation hongroise, variation sur Coluche

liens

[^]Re: liens

[^]Re: liens

Petits avis ans importance

[^]Re: Petits avis ans importance

[^]Re: Petits avis ans importance

[^]Re: Petits avis ans importance

[^]Re: Petits avis ans importance

[^]Re: Petits avis ans importance

[^]Re: Petits avis ans importance

[^]Re: Petits avis ans importance

[^]Re: Petits avis ans importance

facile

[^]Re: facile

[^]Re: facile

[^]Re: facile

[^]Re: facile

Mozilla

[^]wtf

[^]Re: wtf

[^]Re: wtf

[^]Re: wtf

[^]Re: wtf

[^]Re: wtf

Bah heu...

[^]Re: Bah heu...

[^]Re: Bah heu...

y'a pas 1 seule solution