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/
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).
Vous avez demandé le commentaire #791033.
Run by 
Cette page a été générée par Templeet en 0.0546s (dont 0.0052 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Petits avis ans importance
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
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
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
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
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
> 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:
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/top(...)
[^]Re: Petits avis ans importance
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
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
> 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)