Que signifie le préfixe de variable `m_`?

Je vois souvent le m_préfixe utilisé pour les variables ( m_World, m_Sprites...) dans des tutoriels, des exemples et autres codes principalement liés au développement du jeu.

Pourquoi les gens ajoutent-ils un préfixe m_aux variables?

Il s'agit d'une pratique de programmation typique pour définir des variables qui sont des variables membres. Ainsi, lorsque vous les utilisez plus tard, vous n'avez pas besoin de voir où ils sont définis pour connaître leur portée. C'est également génial 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 s'affiche. Une partie de la notation hongroise, voir la partie sur la portée dans les exemples ici .

Dans Clean Code: A Handbook of Agile Software Craftsmanship, il y a 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_. Vos classes et fonctions doivent être suffisamment petites pour que vous n'en ayez pas besoin.

Il existe également un exemple (code C #) de ceci:

Mauvaise pratique:

public class Part
{
    private String m_dsc; // The textual description

    void SetName(string name)
    {
        m_dsc = name;
    }
}

Bonnes pratiques:

public class Part
{
    private String description;

    void SetDescription(string description)
    {
        this.description = description;
    }
}

Nous comptons avec des constructions de langage pour désigner les variables membres dans le cas d'ambiguïté explicitement ( c. -à , descriptionmembre et descriptionparamètres): this.

C'est une pratique courante en C ++. En effet, 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.

http://coliru.stacked-crooked.com/a/f38e7dbb047687ad

"m_" indique 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 différentes conventions / grammaires.

Le m_préfixe est souvent utilisé pour les variables membres - je pense que son principal avantage est qu'il aide à créer une distinction claire entre une propriété publique et la variable de membre privé qui la soutient:

int m_something

public int Something => this.m_something; 

Il peut être utile d'avoir une convention de dénomination cohérente pour les variables de sauvegarde, et le m_préfixe est une façon de le faire - une méthode qui fonctionne dans les langages insensibles à la casse.

Son utilité dépend des langues et des outils que vous utilisez. Les IDE modernes dotés d'outils de refactorisation puissants et d'intellisense ont moins besoin de conventions comme celle-ci, et ce n'est certainement pas la seule façon de le faire, mais cela vaut la peine d'être conscient de la pratique dans tous les cas.

Comme indiqué dans les autres réponses, le m_préfixe est utilisé pour indiquer qu'une variable est un membre de la classe. Ceci est différent 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 langages où «this» ou «self» est obligatoire. Je n'aime pas voir «this->» utilisé avec C ++ car il encombre le code.

Une autre réponse dit m_dscest «mauvaise pratique» et «description»; est une "bonne pratique" mais c'est un hareng rouge parce que le problème là-bas est l'abréviation.

Une autre réponse dit que la saisie fait thisapparaître IntelliSense, mais tout bon IDE aura un raccourci clavier pour afficher IntelliSense pour les membres actuels de la classe.

Comme indiqué dans de nombreuses autres réponses, m_ est un préfixe qui désigne les variables membres. Il est / était couramment utilisé dans le monde C ++ et propagé à d'autres langages, y compris Java.

Dans un IDE moderne, il est complètement redondant car la coloration syntaxique montre clairement quelles variables sont locales et lesquelles sont membres . Cependant, au moment où la coloration syntaxique est apparue à la fin des années 90, la convention existait depuis de nombreuses années et était fermement établie (du moins dans le monde C ++).

Je ne sais pas à quels tutoriels vous faites référence, mais je suppose qu'ils utilisent la convention en raison de l'un des deux facteurs suivants:

• Ce sont des tutoriels C ++, écrits par des personnes habituées à la convention m_, et / ou ...
• Ils écrivent du code en texte brut (monospace), sans coloration syntaxique, la convention m_ est donc utile pour rendre les exemples plus clairs.

Lockheed Martin utilise un schéma de nommage à 3 préfixes avec lequel il était merveilleux de travailler, en particulier lors de la lecture du code des autres.

   Scope          Reference Type(*Case-by-Case)   Type

   member   m     pointer p                       integer n
   argument a     reference r                     short   n
   local    l                                     float   f
                                                  double  f
                                                  boolean b

Alors...

int A::methodCall(float af_Argument1, int* apn_Arg2)
{
    lpn_Temp = apn_Arg2;
    mpf_Oops = lpn_Temp;  // Here I can see I made a mistake, I should not assign an int* to a float*
}

Prenez-le pour ce qu'il vaut.

Pour compléter les réponses actuelles et comme la question n'est pas spécifique au langage, certains projets C utilisent le préfixe m_pour définir des variables globales spécifiques à un fichier - et g_pour les variables globales dont la portée est plus grande que le fichier dans lequel elles sont définies.
Dans ce cas, les variables globales définies avec le préfixe m_ doivent être définies comme static.

Voir la convention de codage EDK2 (une implémentation UEFI Open-Source) pour un exemple de projet utilisant cette convention.

Un argument que je n'ai pas encore vu est qu'un préfixe tel que m_peut être utilisé pour empêcher le nom d'entrer en conflit avec #defineles macros 'd.

Regex recherche #define [a-z][A-Za-z0-9_]*[^(]dans /usr/include/term.hdes malédictions / ncurses.