Je vois souvent m_
préfixe utilisé pour les variables ( m_World
, m_Sprites
...) dans les tutoriels, exemples et autres codes principalement liés au développement de jeux.
Pourquoi les gens ajoutent-ils le préfixe m_
aux variables ?
Je vois souvent m_
préfixe utilisé pour les variables ( m_World
, m_Sprites
...) dans les tutoriels, exemples et autres codes principalement liés au développement de jeux.
Pourquoi les gens ajoutent-ils le préfixe m_
aux variables ?
C'est une pratique de programmation typique pour définir des variables qui sont des variables membres. Ainsi, lorsque vous les utiliserez plus tard, vous n'aurez pas besoin de voir où elles ont été définies pour connaître leur portée. C'est également idéal si vous connaissez déjà la portée et que vous utilisez quelque chose comme intelliSense vous pouvez commencer par m_
et une liste de toutes vos variables membres est affichée. Une partie de la notation hongroise, voir la partie sur la portée dans la section exemples ici .
Le pire argument pour une convention de nommage, vous pouvez simplement appuyer sur ctrl+espace pour l'intellisense.
@nightcracker bien que je n'aime pas le préfixe, il veut dire que lorsque vous tapez m_ et ensuite " CTRL + SPACE " ( sauf si c'est automatique) vous obtenez une liste contenant uniquement vos membres. Pas vraiment une bonne raison mais c'est un plus.
@nightcracker Pas sûr si vous essayez d'être drôle ou juste naïf. Il fut un temps avant intellisense et il y a encore un grand nombre de personnes qui ne l'utilisent pas. Je suis no disant qu'intellisense est la raison d'utiliser cette convention de nom. Je dis que c'est un avantage supplémentaire si vous utilisez intellisense. Les conventions de nommage servent à rendre le code plus clair et à maintenir un standard.
Sur Code propre : Un manuel d'artisanat logiciel agile il existe une recommandation explicite contre l'utilisation de ce préfixe :
Vous n'avez pas non plus besoin de préfixer les variables membres avec
m_
plus. Vos classes et fonctions doivent être suffisamment petites pour que vous n'en ayez pas besoin.
Il existe également un exemple (code C#) :
Mauvaise pratique :
public class Part
{
private String m_dsc; // The textual description
void SetName(string name)
{
m_dsc = name;
}
}
Bonne pratique :
public class Part
{
private String description;
void SetDescription(string description)
{
this.description = description;
}
}
Nous comptons avec des constructions linguistiques pour faire référence aux variables membres en cas d'ambiguïté explicite ( c'est-à-dire , description
membre et description
paramètre) : this
.
La formulation pourrait être "il existe une recommandation explicite CONTRE l'utilisation de ce préfixe :".
Une autre raison est qu'en java les getter/setter sont supposés être getName/setName, donc getM_name est mauvais et vous devez les gérer un par un.
C'est une pratique courante en C++. C'est parce qu'en C++, vous ne pouvez pas avoir le même nom pour la fonction membre et la variable membre, et les fonctions getter sont souvent nommées sans le préfixe "get".
class Person
{
public:
std::string name() const;
private:
std::string name; // This would lead to a compilation error.
std::string m_name; // OK.
};
main.cpp:9:19: error: duplicate member 'name' std::string name; ^ main.cpp:6:19: note: previous declaration is here std::string name() const; ^ 1 error generated.
"m_" désigne le "membre". Le préfixe "_" est également courant.
Vous ne devriez pas l'utiliser dans les langages de programmation qui résolvent ce problème en utilisant des conventions/une grammaire différentes.
El m_
est souvent utilisé pour les variables membres - je pense que son principal avantage est qu'il permet de créer une distinction claire entre une propriété publique et la variable membre privée qui la soutient :
int m_something
public int Something => this.m_something;
Il peut être utile de disposer d'une convention d'appellation cohérente pour les variables de sauvegarde, et la fonction m_
Le préfixe est un moyen de le faire, qui fonctionne dans les langues insensibles à la casse.
L'utilité de ces outils dépend des langues et des outils que vous utilisez. Les IDE modernes dotés d'outils de refactoring et d'intellisense puissants ont moins besoin de conventions de ce type, et ce n'est certainement pas la seule façon de procéder, mais il vaut la peine d'être conscient de cette pratique dans tous les cas.
@Ruslan le m_
est de le distinguer de la propriété qu'il soutient - donc this.Something
pour la propriété vs this.m_something
pour le membre de soutien. Ce n'est pas une convention que je préfère moi-même, mais je l'ai surtout vue utilisée dans des langages insensibles à la casse (comme VB).
Pourquoi pas, this.Something
pour la propriété et this.something
pour le support ? Ou this._something
pour le support ? this.m_something
est redondant. J'utilise _something
afin que je ne le tape pas accidentellement quand je vais taper Something
rien à voir avec le fait d'être membre ou non
Comme indiqué dans les autres réponses, m_
est utilisé pour indiquer qu'une variable est un membre de classe. Cette notation est différente de la notation hongroise car elle n'indique pas le type de la variable mais son contexte.
J'utilise m_
en C++ mais pas dans d'autres langues où "this" ou "self" est obligatoire. Je n'aime pas voir 'this->' utilisé en C++ car il encombre le code.
Une autre réponse dit m_dsc
est une "mauvaise pratique" et "description" une "bonne pratique", mais il s'agit d'un faux-fuyant, car le problème réside dans l'abréviation.
Une autre réponse dit de taper this
fait apparaître IntelliSense mais tout bon IDE dispose d'un raccourci pour faire apparaître IntelliSense pour les membres de la classe courante.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
3 votes
Voir fr.wikipedia.org/wiki/Hungarian_notation
26 votes
Avant de suivre aveuglément l'exemple de la notation hongroise, veuillez vérifier ce qu'est réellement la notation hongroise. Parce que nommer un int iCounter est tout simplement inutile. Mais nommer un int xAnnotationPos et yAnnotationPos est raisonnable. Utilisez la version sémantique.
0 votes
Parfois, les modules importés préfixent les fonctions et les variables afin que vous soyez moins susceptible de les écraser avec votre propre code. C'est une façon de "réserver" des noms pour un usage spécifique.
0 votes
Byte56 vous a donné une réponse. J'ai vu des outils qui s'appuient sur une convention de nommage telle que mVariable pour générer du code supplémentaire, de la documentation (oui) et automatiser certaines tâches redondantes sur certaines variables membres...
5 votes
Bien que la notation "hongroise" soit souvent méchamment tournée en dérision, la forme particulière de cette notation qui indique la portée des variables présente de réels avantages. En plus d'identifier la portée de la variable, elle empêche les collisions de noms, comme lorsqu'un local, un parm et un member ont tous la même intention, et donc le même nom "sémantique". Cela peut rendre la maintenance de grandes bases de code plus simple et moins sujette aux erreurs.
0 votes
Duplicata de Pourquoi les noms de variables commencent-ils souvent par la lettre "m" ?
19 votes
Il y a des arguments pour et contre toute norme de codage, mais la question demande clairement ce qui est
m_
Pourtant, la moitié des réponses ici sont des commentaires sur les raisons pour lesquelles chacun pense que son favori actuel est le meilleur.