¿Qué significa el prefijo de variable `m_`?

A menudo veo m_prefijo utilizado para las variables ( m_World, m_Sprites, ...) en tutoriales, ejemplos y otros códigos relacionados principalmente con el desarrollo del juego.

¿Por qué la gente agrega prefijo m_a las variables?

Esta es una práctica de programación típica para definir variables que son variables miembro. Entonces, cuando los use más adelante, no necesita ver dónde están definidos para conocer su alcance. Esto también es genial si ya conoce el alcance y está usando algo como intelliSense , puede comenzar m_y se muestra una lista de todas sus variables miembro. Parte de la notación húngara, vea la parte sobre el alcance en los ejemplos aquí .

En Clean Code: A Handbook of Agile Software Craftsmanship hay una recomendación explícita contra el uso de este prefijo:

Tampoco necesita prefijar las variables miembro con m_más. Sus clases y funciones deben ser lo suficientemente pequeñas como para que no las necesite.

También hay un ejemplo (código C #) de esto:

Mala práctica:

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

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

Buena práctica:

public class Part
{
    private String description;

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

Contamos con construcciones de lenguaje para referirse a variables miembro en el caso de la ambigüedad de manera explícita ( es decir , descriptionmiembros y descriptionparámetros): this.

Es una práctica común en C ++. Esto se debe a que en C ++ no puede tener el mismo nombre para la función miembro y la variable miembro, y las funciones getter a menudo se nombran sin el prefijo "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_" indica para el "miembro". El prefijo "_" también es común.

No debe usarlo en lenguajes de programación que resuelvan este problema usando diferentes convenciones / gramática.

El m_prefijo se usa a menudo para las variables miembro; creo que su principal ventaja es que ayuda a crear una distinción clara entre una propiedad pública y la variable miembro privada que la respalda:

int m_something

public int Something => this.m_something; 

Puede ser útil tener una convención de nomenclatura coherente para las variables de respaldo, y el m_prefijo es una forma de hacerlo, una que funciona en lenguajes que no distinguen entre mayúsculas y minúsculas.

La utilidad de esto depende de los idiomas y las herramientas que esté utilizando. Los IDE modernos con herramientas de refactorización e intellisense fuertes tienen menos necesidad de convenciones como esta, y ciertamente no es la única forma de hacerlo, pero vale la pena estar al tanto de la práctica en cualquier caso.

Como se indica en las otras respuestas, el m_prefijo se usa para indicar que una variable es un miembro de la clase. Esto es diferente de la notación húngara porque no indica el tipo de la variable sino su contexto.

Lo uso m_en C ++ pero no en otros lenguajes donde 'this' o 'self' es obligatorio. No me gusta ver 'this->' usado con C ++ porque satura el código.

Otra respuesta dice m_dsces "mala práctica" y "descripción"; es una "buena práctica" pero es un arenque rojo porque el problema es la abreviatura.

Otra respuesta dice que escribir thisaparece IntelliSense, pero cualquier buen IDE tendrá una tecla de acceso rápido para mostrar IntelliSense para los miembros de la clase actual.

Como se indica en muchas otras respuestas, m_ es un prefijo que denota variables miembro. Es / fue comúnmente usado en el mundo C ++ y también se propagó a otros lenguajes, incluido Java.

En un IDE moderno es completamente redundante ya que el resaltado de sintaxis hace evidente qué variables son locales y cuáles son miembros . Sin embargo, cuando el resaltado de sintaxis apareció a fines de los 90, la convención había existido durante muchos años y estaba firmemente establecida (al menos en el mundo de C ++).

No sé a qué tutoriales se refiere, pero supongo que están usando la convención debido a uno de dos factores:

• Son tutoriales de C ++, escritos por personas acostumbradas a la convención m_, y / o ...
• Escriben código en texto plano (monoespaciado), sin resaltado de sintaxis, por lo que la convención m_ es útil para aclarar los ejemplos.

Lockheed Martin utiliza un esquema de nomenclatura de 3 prefijos con el que fue maravilloso trabajar, especialmente al leer el código de otros.

   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

Entonces...

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*
}

Tómelo por lo que vale.

Para completar las respuestas actuales y como la pregunta no es específica del lenguaje, algunos proyectos C usan el prefijo m_para definir variables globales que son específicas de un archivo, y g_para las variables globales que tienen un alcance mayor que el archivo que están definidas.
En este caso, las variables globales definidas con prefijo m_ deben definirse como static.

Consulte la convención de codificación EDK2 (una implementación UEFI de código abierto) para ver un ejemplo de proyecto que usa esta convención.

Un argumento que aún no he visto es que m_se puede usar un prefijo como para evitar que el nombre entre en conflicto con #define'd macro's.

Búsqueda de expresiones regulares desde #define [a-z][A-Za-z0-9_]*[^(]in /usr/include/term.hcurses / ncurses.