son - variables de texto en c++

Convenciones de nomenclatura variable en C++

Question

Vengo de un mundo .NET y soy nuevo en la escritura de C ++. Me pregunto cuáles son las convenciones de nomenclatura preferidas a la hora de nombrar las variables locales y los miembros de la estructura.

Por ejemplo, el código heredado que he heredado tiene muchos de estos:

struct MyStruct
{
   TCHAR           szMyChar[STRING_SIZE];
   bool            bMyBool;
   unsigned long   ulMyLong;
   void*           pMyPointer;
   MyObject**      ppMyObjects;
}

Viniendo de un fondo de C # me sorprendió ver las variables con notación húngara (no pude dejar de reírme del prefijo pp la primera vez que lo vi).

Preferiría nombrar mis variables de esta manera en su lugar (aunque no estoy seguro si capitalizar la primera letra es una buena convención. He visto otras formas (ver enlaces a continuación)):

struct MyStruct
{
   TCHAR           MyChar[STRING_SIZE];
   bool            MyBool;
   unsigned long   MyLong;
   void*           MyPointer;
   MyObject**      MyObjects;
}

Mi pregunta: ¿sigue siendo (de la manera anterior) una forma preferida de nombrar variables en C ++?

Referencias

http://geosoft.no/development/cppstyle.html

http://www.syntext.com/books/syntext-cpp-conventions.htm

http://ootips.org/hungarian-notation.html

¡Gracias!

Answer 1

¿Qué es lo que no les gusta o se burlan de "ppMyObjects" en este ejemplo, aparte de que es algo feo? No tengo opiniones sólidas de ninguna manera, pero sí comunica información útil de un vistazo que "MyObjects" no contiene.

Answer 2

Creo que todavía encontrará que la mayoría de las tiendas que programan en Visual C ++ se adhieren a la notación húngara o al menos a una versión diluida de la misma. En nuestra tienda, la mitad de nuestra aplicación es C ++ heredado con una nueva capa brillante C # en la parte superior (con una capa administrada de C ++ en el medio). Nuestro código C ++ continúa usando notación húngara pero nuestro código C # usa notación como la que presentó. Creo que es feo, pero es consistente.

Yo digo, usa lo que tu equipo quiera para tu proyecto. Pero si está trabajando con un código heredado o uniéndose a un equipo, quédese con el estilo que está presente para lograr consistencia.

Answer 3

Ese tipo de notación húngara es bastante inútil, y posiblemente peor que inútil si tienes que cambiar el tipo de algo. ( El tipo apropiado de notación húngara es una historia diferente).

Te sugiero que uses lo que sea que tu grupo haga. Si usted es la única persona que trabaja en el programa, asígneles el nombre que sea más lógico para usted.

Answer 4

Estoy de acuerdo con las otras respuestas aquí. Continúa usando el estilo que se te ha dado desde la última vez, por razones de consistencia, o crea una nueva convención que funcione para tu equipo. Es importante que el equipo esté de acuerdo, ya que es casi seguro que va a cambiar los mismos archivos. Habiendo dicho eso, algunas cosas que encontré muy intuitivas en el pasado:

Las variables de miembro de clase / estructura deben destacarse. Generalmente las prefijo con m_
Las variables globales deberían sobresalir: el prefijo usuall con g_
Las variables en general deberían comenzar con minúsculas
Los nombres de las funciones en general deben comenzar con mayúsculas
Macros y posiblemente enumeraciones deben ser todas mayúsculas
Todos los nombres deben describir lo que hace la función / variable, y nunca deben describir su tipo o valor.

Answer 5

La notación húngara era común entre los usuarios de las API de Win32 y MFC. Si sus predecesores estaban usando eso, probablemente sea mejor que continúe usándolo (aunque sea una mierda). El resto del mundo C ++ nunca tuvo esta convención de muerte cerebral, así que no la uses si estás usando algo diferente a esas API.

Answer 6

Lo más importante es ser consistente. Si está trabajando con una base de código heredada, asigne un nombre a sus variables y funciones de forma coherente con la convención de nomenclatura del código heredado. Si está escribiendo un código nuevo que solo está interactuando con el código anterior, use su convención de nomenclatura en el nuevo código, pero sea coherente consigo mismo también.

Answer 7

No. La "notación húngara incorrecta", especialmente las pp para doble indirección, tenía sentido para los primeros compiladores de C, donde se podía escribir

int * i = 17;
int j = ***i;

sin siquiera una advertencia del compilador (y que incluso podría ser un código válido en el hardware correcto ...).

La "notación húngara verdadera" (como se vincula por el jefe Geek) es IMO sigue siendo una opción válida, pero no necesariamente preferida. Una aplicación moderna de C ++ generalmente tiene docenas o cientos de tipos, para los cuales no encontrará los prefijos adecuados.

Todavía lo uso localmente en algunos casos en los que tengo que mezclar, por ejemplo, variables enteras y flotantes que tienen nombres muy similares o incluso idénticos en el dominio del problema, por ejemplo

float fXmin, fXmax, fXpeak; // x values of range and where y=max
int   iXmin, iXMax, iXpeak; // respective indices in x axis vector

Sin embargo, cuando se mantiene el código heredado que sigue algunas convenciones de forma coherente (aunque poco estricto), debe seguir las convenciones utilizadas allí, al menos en los módulos / unidades de compilación existentes que se mantendrán.

Mi razonamiento: el propósito de los estándares de codificación es cumplir con el principio de menor sorpresa. Usar un estilo consistentemente es más importante que el estilo que uses.

Answer 8

Nuestro equipo usa la convención del código de Google C ++ :

Esta es una muestra del nombre de la variable:

string table_name;  // OK - uses underscore.
string tablename;   // OK - all lowercase.

string tableName;   // Bad - mixed case.

Answer 9

Si usa CamelCase, la convención es para poner en mayúscula la primera letra para los tipos de clases y los nombres de tipo no primitivos, y en minúscula la primera letra para los miembros de datos. La capitalización de los métodos tiende a ser una mezcla, mis métodos tienden a ser verbos y ya son distinguidos por los paréntesis, así que no capitalizo los métodos.

Personalmente, no me gusta leer el código de CamelCase y prefiero subrayar minúsculas para identificadores de datos y métodos, capitalizar tipos y reservar mayúsculas para acrónimos y el raro caso en que utilizo una macro (advirtiendo que es una MACRO).

Answer 10

Soy una persona de notación húngara, porque me parece que presta legibilidad al código, y prefiero el código de auto-documentación para comentarios y búsquedas.

Dicho esto, creo que puedes justificar sacrificando tu estilo preferido y algo de mantenibilidad adicional para la unidad del equipo. No me gusta el argumento de la coherencia en aras de la legibilidad del código uniforme, especialmente si su legibilidad reductora para la consistencia ... simplemente no tiene sentido. Sin embargo, llevarse bien con las personas con las que trabajas podría valer la pena un poco más de confusión en los tipos que miran las variables.

Answer 11

También prefiero CamelCase, de hecho, en su mayoría he visto gente usando CamelCase en C ++. Personalmente, no uso prefijos para interfaces y miembros privados / protegidos:

class MyClass : public IMyInterface {
public:
    unsigned int PublicMember;
    MyClass() : PublicMember(1), _PrivateMember(0), _ProtectedMember(2) {}
    unsigned int PrivateMember() {
        return _PrivateMember * 1234; // some senseless calculation here
    }
protected:
    unsigned int _ProtectedMember;
private:
    unsigned int _PrivateMember;
};
// ...
MyClass My;
My.PublicMember = 12345678;

Por qué decidí omitir los prefijos para los miembros públicos: porque se podía acceder a los miembros públicos directamente como en las estructuras y no chocar con los nombres privados. En lugar de usar caracteres de subrayado, también he visto personas que usan la primera letra minúscula para los miembros.

struct IMyInterface {
    virtual void MyVirtualMethod() = 0;
};

Interfaces contiene por definición solo métodos virtuales puros que deben implementarse más adelante. Sin embargo, en la mayoría de las situaciones prefiero las clases abstractas, pero esta es otra historia.

struct IMyInterfaceAsAbstract abstract {
    virtual void MyVirtualMethod() = 0;
    virtual void MyImplementedMethod() {}
    unsigned int EvenAnPublicMember;
};

Consulte el Manual del estándar de codificación High Integrity C ++ para obtener más inspiración.

Answer 12

Todo se reduce a las preferencias personales. He trabajado para 2 compañías con esquemas similares, donde los miembros vars se nombran como m_varName. Nunca he visto la notación húngara en uso en el trabajo, y realmente no me gusta, pero de nuevo a las preferencias. Mi opinión general es que IDE debe ocuparse de decirte de qué tipo es, por lo que siempre que el nombre sea suficientemente descriptivo de lo que hace (m_color, m_shouldBeRenamed), entonces está bien. La otra cosa que me gusta es la diferencia entre la variable miembro, var local y nomenclatura constante, por lo que es fácil ver lo que está sucediendo en una función y de dónde provienen los vars. Miembro: m_varName Const: c_varName local: varName