Salut a tous!
Je suis entrain de cleanner un code que j'ai fait pour qu'il soit
reprenable par d'autres.
j'ai recupéré deux docs sur des regles de notation regulierement utilise
(exemple le p devant le nom d'une variable de type pointeur)
Sauf que sur certains trucs elles sont pas d'accord :-)
les noms des arguments des methodes:
soit premier charactere en minuscule puis chaque debut de mot en
majuscule (ex: methode(int maVariable);)
soit la meme chose mais avec un _ au debut (ex: methode(int _maVariable);)
laquelle de ces deux notation vous semble la plus propre?
dans une de ces docs il y a pour les attributs des classes un "m" en prefixe
(ex: int mVarAbc;
string* mpName;)
l'idee est d'eviter les conflits de nom avec les methodes de la classe
mais pourquoi un "m" ?
Si vous avez des sites ou des ressources (pdf par ex) sur la mise en
forme d'un projet opensource en c++ (syntaxe, regles de nommage ou
d'arborescence, fichiers standards,...) je suis preneur
Reprenons l'exemple de l'article : il faudrait un type "chaîne fiable" et un type "chaîne non fiable".
Plutôt que fiable/non fiable, je parlerais plutôt de deux encodages différents.
En l'absence d'un "typedef" un peu plus souple qu'un #define (i.e. un machin qui permettrait de définir deux types au même comportement mais tout de même différentiables[*]), comment proposes-tu d'implémenter ces deux types ?
Par des templates (éventuellement n'utilisant pas leur paramètre template) ?
template <class Differenciateur> class Type { /*...*/ };
class TagTexteFiable{}; class TagTexteNonFiable{};
En fait, le plus chaud est de définir le type Type, surtout s'il doit ressembler à un type de base spécifique à l'interface démesurée (lire std::string), et interagir avec du code ne le connaissant pas.
Dans le cas particulier des strings, je me demande s'il serait possible de faire ça à l'aide d'un std::basic_string<CaractereFiable>. J'avoue ne jamais avoir eu le courage de me plonger dans les locales/char_traits... pour savoir si ça aurait une chance d'aboutir.
[*] J'aimerais bien un système où, étant donné un type A, je pourrais définir un type B, avec les mêmes membres, une conversion implicite de A vers B, de B vers A, de A* vers B*, et de B* vers A*, mais tout de même distincts.
Il suffit d'écrire les fonctions de convertions templates de Type<T> vers Type<U>...
Par contre, en l'occurence, je préfère une convertion explicite.
-- Loïc
Reprenons l'exemple de l'article : il faudrait un type "chaîne fiable"
et un type "chaîne non fiable".
Plutôt que fiable/non fiable, je parlerais plutôt de deux encodages
différents.
En l'absence d'un "typedef" un peu plus souple qu'un #define (i.e. un
machin qui permettrait de définir deux types au même comportement mais
tout de même différentiables[*]), comment proposes-tu d'implémenter
ces deux types ?
Par des templates (éventuellement n'utilisant pas leur paramètre template) ?
template <class Differenciateur> class Type
{
/*...*/
};
class TagTexteFiable{};
class TagTexteNonFiable{};
En fait, le plus chaud est de définir le type Type, surtout s'il doit
ressembler à un type de base spécifique à l'interface démesurée (lire
std::string), et interagir avec du code ne le connaissant pas.
Dans le cas particulier des strings, je me demande s'il serait possible
de faire ça à l'aide d'un std::basic_string<CaractereFiable>. J'avoue ne
jamais avoir eu le courage de me plonger dans les locales/char_traits...
pour savoir si ça aurait une chance d'aboutir.
[*] J'aimerais bien un système où, étant donné un type A, je pourrais
définir un type B, avec les mêmes membres, une conversion implicite de
A vers B, de B vers A, de A* vers B*, et de B* vers A*, mais tout de
même distincts.
Il suffit d'écrire les fonctions de convertions templates de Type<T>
vers Type<U>...
Par contre, en l'occurence, je préfère une convertion explicite.
Reprenons l'exemple de l'article : il faudrait un type "chaîne fiable" et un type "chaîne non fiable".
Plutôt que fiable/non fiable, je parlerais plutôt de deux encodages différents.
En l'absence d'un "typedef" un peu plus souple qu'un #define (i.e. un machin qui permettrait de définir deux types au même comportement mais tout de même différentiables[*]), comment proposes-tu d'implémenter ces deux types ?
Par des templates (éventuellement n'utilisant pas leur paramètre template) ?
template <class Differenciateur> class Type { /*...*/ };
class TagTexteFiable{}; class TagTexteNonFiable{};
En fait, le plus chaud est de définir le type Type, surtout s'il doit ressembler à un type de base spécifique à l'interface démesurée (lire std::string), et interagir avec du code ne le connaissant pas.
Dans le cas particulier des strings, je me demande s'il serait possible de faire ça à l'aide d'un std::basic_string<CaractereFiable>. J'avoue ne jamais avoir eu le courage de me plonger dans les locales/char_traits... pour savoir si ça aurait une chance d'aboutir.
[*] J'aimerais bien un système où, étant donné un type A, je pourrais définir un type B, avec les mêmes membres, une conversion implicite de A vers B, de B vers A, de A* vers B*, et de B* vers A*, mais tout de même distincts.
Il suffit d'écrire les fonctions de convertions templates de Type<T> vers Type<U>...
Par contre, en l'occurence, je préfère une convertion explicite.
-- Loïc
Benoît Bréholée
Herode wrote:
m = member Ceci dit, je trouve ça ridicule. Mais là encore, ça n'engage que moi.
Pas tant que ça. Dans les méthodes dépassant la vingtaine de lignes,
ça permet facilement de savoir qui est une variable membre et qui ne l'est pas.
Ça me donne l'impression d'être une solution à un problème qui n'est qu'une conséquence d'un autre problème... et il serait sans doute plus pertinent de revenir à la source. Si ce besoin de « facilement savoir qui est une variable membre et qui ne l'est pas » apparaît : - cette fonction membre (ou cette classe) n'est-elle pas trop complexe ? - les noms de variables et d'attributs ne devraient-ils pas être un peu plus explicites ?
L'inconvénient du préfixe, en tant que style de code, c'est qu'il risque de n'être utile qu'à une minorité de fonctions membres parmi une minorité de classes, mais que sa lourdeur (visuelle) s'imposera partout...
Herode wrote:
m = member
Ceci dit, je trouve ça ridicule. Mais là encore, ça n'engage que moi.
Pas tant que ça. Dans les méthodes dépassant la vingtaine de lignes,
ça permet facilement de savoir qui est une variable membre et qui ne
l'est pas.
Ça me donne l'impression d'être une solution à un problème qui n'est
qu'une conséquence d'un autre problème... et il serait sans doute plus
pertinent de revenir à la source. Si ce besoin de « facilement savoir
qui est une variable membre et qui ne l'est pas » apparaît :
- cette fonction membre (ou cette classe) n'est-elle pas trop complexe ?
- les noms de variables et d'attributs ne devraient-ils pas être un
peu plus explicites ?
L'inconvénient du préfixe, en tant que style de code, c'est qu'il risque
de n'être utile qu'à une minorité de fonctions membres parmi une minorité
de classes, mais que sa lourdeur (visuelle) s'imposera partout...
m = member Ceci dit, je trouve ça ridicule. Mais là encore, ça n'engage que moi.
Pas tant que ça. Dans les méthodes dépassant la vingtaine de lignes,
ça permet facilement de savoir qui est une variable membre et qui ne l'est pas.
Ça me donne l'impression d'être une solution à un problème qui n'est qu'une conséquence d'un autre problème... et il serait sans doute plus pertinent de revenir à la source. Si ce besoin de « facilement savoir qui est une variable membre et qui ne l'est pas » apparaît : - cette fonction membre (ou cette classe) n'est-elle pas trop complexe ? - les noms de variables et d'attributs ne devraient-ils pas être un peu plus explicites ?
L'inconvénient du préfixe, en tant que style de code, c'est qu'il risque de n'être utile qu'à une minorité de fonctions membres parmi une minorité de classes, mais que sa lourdeur (visuelle) s'imposera partout...
Fabien LE LEZ
On Thu, 02 Mar 2006 01:44:53 +0100, Loïc Joly :
Par contre, en l'occurence, je préfère une convertion explicite.
Exact. Il faudra prévoir les deux : pseudo_typedef et pseudo_typedef_explicit.
On Thu, 02 Mar 2006 01:44:53 +0100, Loïc Joly
<loic.actarus.joly@numericable.fr>:
Par contre, en l'occurence, je préfère une convertion explicite.
Exact. Il faudra prévoir les deux : pseudo_typedef et
pseudo_typedef_explicit.
Par contre, en l'occurence, je préfère une convertion explicite.
Exact. Il faudra prévoir les deux : pseudo_typedef et pseudo_typedef_explicit.
Fabien LE LEZ
On Thu, 02 Mar 2006 01:44:53 +0100, Loïc Joly :
En fait, le plus chaud est de définir le type Type, surtout s'il doit ressembler à un type de base spécifique à l'interface démesurée (lire std::string), et interagir avec du code ne le connaissant pas.
Hé oui. C'est bien le problème. Et la solution proposée par Joel Spolsky n'est pas forcément si bête que ça.
On Thu, 02 Mar 2006 01:44:53 +0100, Loïc Joly
<loic.actarus.joly@numericable.fr>:
En fait, le plus chaud est de définir le type Type, surtout s'il doit
ressembler à un type de base spécifique à l'interface démesurée (lire
std::string), et interagir avec du code ne le connaissant pas.
Hé oui. C'est bien le problème. Et la solution proposée par Joel
Spolsky n'est pas forcément si bête que ça.
En fait, le plus chaud est de définir le type Type, surtout s'il doit ressembler à un type de base spécifique à l'interface démesurée (lire std::string), et interagir avec du code ne le connaissant pas.
Hé oui. C'est bien le problème. Et la solution proposée par Joel Spolsky n'est pas forcément si bête que ça.
Patrick 'Zener' Brunet
Bonjour.
Je réponds à 3dsman
[...] J'ai developpe ce soft en decouvrant au fur et a mesure des normes de codage et de mise en page.
Oui, ça arrive et c'est très bien lorsqu'on prend de l'expérience. Mais je pense qu'il faut rester homogène dans le cadre d'un projet donné. On prend des bonnes résolutions pour le prochain.
Mon code est relativement propre (enfin je crois) mais on m'as fait la remarque qu'on dirait qu'il a ete ecrit par plusieurs personnes :-)
Déjà, avez-vous fait l'effort de rédiger votre standard (même sous forme d'un simple brouillon) ?
Ca vous aiderait â faire mentalement le procès de telle ou telle règle, et à faire des choix bien clairs.
Ca vous permettrait ensuite, si vous le rédigez, d'avoir un tel mode d'emploi à livrer avec votre code (selon le principe que j'ai précédemment décrit).
J'essaye donc d'homogeneïser tout ca. Au niveau des noms de variables, des noms de methodes, de classes,...
C'est le gros problème très chronophage pour un projet. Si vous avez le sens de l'esthétique, je comprends très bien que vous en ayez envie. Mais vous risquez d'entrer dans une spirale perfectionniste parce que vous allez encore améliorer votre standard...
Si vous découpez en modules (c'est assez petit un module) et si vous acceptez l'idée qu'un module dans son état livrable sera réutilisé **extérieurement** jusqu'au jour où il sera **remplacé** ou **reconstruit**, alors votre style va évoluer tout en restant homogène et donc cohérent pour un module donné.
Et donc vous restez libre d'améliorer votre style sans que ça devienne un carcan.
Si ca ne vous derange pas quand il sera un peu plus propre je vous mettrais une copie sur mon site pour que vous me donniez votre avis.
Ce ne sera donc que mon avis, forcément chargé de subjectivité.
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à 3dsman <3dsman@free.fr>
[...]
J'ai developpe ce soft en decouvrant au fur et a mesure des normes de
codage et de mise en page.
Oui, ça arrive et c'est très bien lorsqu'on prend de l'expérience.
Mais je pense qu'il faut rester homogène dans le cadre d'un projet donné. On
prend des bonnes résolutions pour le prochain.
Mon code est relativement propre (enfin je crois) mais on m'as fait la
remarque qu'on dirait qu'il a ete ecrit par plusieurs personnes :-)
Déjà, avez-vous fait l'effort de rédiger votre standard (même sous forme
d'un simple brouillon) ?
Ca vous aiderait â faire mentalement le procès de telle ou telle règle, et à
faire des choix bien clairs.
Ca vous permettrait ensuite, si vous le rédigez, d'avoir un tel mode
d'emploi à livrer avec votre code (selon le principe que j'ai précédemment
décrit).
J'essaye donc d'homogeneïser tout ca.
Au niveau des noms de variables, des noms de methodes, de classes,...
C'est le gros problème très chronophage pour un projet. Si vous avez le sens
de l'esthétique, je comprends très bien que vous en ayez envie. Mais vous
risquez d'entrer dans une spirale perfectionniste parce que vous allez
encore améliorer votre standard...
Si vous découpez en modules (c'est assez petit un module) et si vous
acceptez l'idée qu'un module dans son état livrable sera réutilisé
**extérieurement** jusqu'au jour où il sera **remplacé** ou **reconstruit**,
alors votre style va évoluer tout en restant homogène et donc cohérent pour
un module donné.
Et donc vous restez libre d'améliorer votre style sans que ça devienne un
carcan.
Si ca ne vous derange pas quand il sera un peu plus propre je vous
mettrais une copie sur mon site pour que vous me donniez votre avis.
Ce ne sera donc que mon avis, forcément chargé de subjectivité.
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
[...] J'ai developpe ce soft en decouvrant au fur et a mesure des normes de codage et de mise en page.
Oui, ça arrive et c'est très bien lorsqu'on prend de l'expérience. Mais je pense qu'il faut rester homogène dans le cadre d'un projet donné. On prend des bonnes résolutions pour le prochain.
Mon code est relativement propre (enfin je crois) mais on m'as fait la remarque qu'on dirait qu'il a ete ecrit par plusieurs personnes :-)
Déjà, avez-vous fait l'effort de rédiger votre standard (même sous forme d'un simple brouillon) ?
Ca vous aiderait â faire mentalement le procès de telle ou telle règle, et à faire des choix bien clairs.
Ca vous permettrait ensuite, si vous le rédigez, d'avoir un tel mode d'emploi à livrer avec votre code (selon le principe que j'ai précédemment décrit).
J'essaye donc d'homogeneïser tout ca. Au niveau des noms de variables, des noms de methodes, de classes,...
C'est le gros problème très chronophage pour un projet. Si vous avez le sens de l'esthétique, je comprends très bien que vous en ayez envie. Mais vous risquez d'entrer dans une spirale perfectionniste parce que vous allez encore améliorer votre standard...
Si vous découpez en modules (c'est assez petit un module) et si vous acceptez l'idée qu'un module dans son état livrable sera réutilisé **extérieurement** jusqu'au jour où il sera **remplacé** ou **reconstruit**, alors votre style va évoluer tout en restant homogène et donc cohérent pour un module donné.
Et donc vous restez libre d'améliorer votre style sans que ça devienne un carcan.
Si ca ne vous derange pas quand il sera un peu plus propre je vous mettrais une copie sur mon site pour que vous me donniez votre avis.
Ce ne sera donc que mon avis, forcément chargé de subjectivité.
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Marc Boyer
Le 01-03-2006, Fabien LE LEZ a écrit :
On 1 Mar 2006 08:52:04 -0800, "Herode" :
méthodes dépassant la vingtaine de lignes,
Ça existe, ça ?
Ben, moi je n'en rencontre pas souvent, mais visiblement, Herode en a rencontré.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 01-03-2006, Fabien LE LEZ <gramster@gramster.com> a écrit :
On 1 Mar 2006 08:52:04 -0800, "Herode" <cbrun@geomapgis.com>:
méthodes dépassant la vingtaine de lignes,
Ça existe, ça ?
Ben, moi je n'en rencontre pas souvent, mais visiblement,
Herode en a rencontré.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
