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 de la herencia que he inheritted tiene una gran cantidad 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 la notación húngara (que no podía dejar de reír en el prefijo pp la primera vez que lo vi).

yo preferiría nombrar mis variables de este modo en su lugar (aunque no estoy seguro de si mayúscula la primera letra es una buena convención que he visto otras maneras (ver enlaces más abajo).):

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

Mi pregunta: ¿Es esta (la forma anterior) todavía 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

Ese tipo de notación húngara es bastante inútil, y posiblemente peor que inútil si tiene que cambiar el tipo de algo. (The proper kind of Hungarian Notation es una historia diferente.)

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

Answer 2

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 3

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.

Digo, use lo que su equipo quiera para su 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 4

Lo más importante es ser consecuente. Si está trabajando con una base de código heredada, asigne un nombre a sus variables y funciones consistentemente 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 5

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.Una vez dicho esto, algunas cosas que me pareció muy intuitivo en el pasado:

Clase/struct variables miembro deben sobresalir - por lo general de prefijo a todos con m _
Las variables globales deben sobresalir - prefijo usuall con g _
las variables en general deberían comenzar con minúsculas
los nombres de funciones, en general, debe comenzar con mayúscula
macros y, posiblemente, las enumeraciones deben estar todo en mayúsculas
Todos los nombres deben describir lo que hace la función/variable y nunca deben describir su tipo o valor.

Answer 6

¿Qué le desagrada o se burla 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 7

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 puede justificar el sacrificio de su 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 8

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. de usuario: m_varName Const: c_varName locales: varName

Answer 9

Nº La "notación húngara equivocado" - especialmente el PP para indirecto doble - tenía algún sentido para los primeros compiladores de C, donde se podrí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 la cabeza 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 donde tengo que mezclar p. Ej. variables enteras y flotantes que tienen nombres muy similares o incluso idénticos en el dominio del problema, p.

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 el mantenimiento de código heredado que hace seguir algunas convenciones constantemente (aunque débilmente), usted debe pegarse a las convenciones utilizadas allí - por lo menos en los módulos existentes/unidades de compilación que se mantenga.

Mi razonamiento: El objetivo de las normas 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 10

Si utiliza CamelCase, la convención es Capitalizar la primera letra para clases de estructuras y nombres de tipos no primitivos, y minúsculas 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 se distinguen por los paréntesis, por lo que no capitalizo los métodos.

personalmente no me gusta leer código CamelCase y prefieren subraya minúsculas para datos e identificadores de método, aprovechando tipos y reservando las mayúsculas para los acrónimos y el raro caso utilizo una macro (advertencia Ésta es una macro) .

Answer 11

También prefiero CamelCase, de hecho, en su mayoría he visto personas que usan CamelCase en C++. Personalmente no utilizo ningún prefijo esperan para los miembros privados/protegidas e interfaces:

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 del público: Debido a miembros del público se puede acceder directamente al igual que en estructuras y no choquen con 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; 
}; 

Ver High Integrity C++ Coding Standard Manual de pot.

Answer 12

Nuestro uso del equipo Google C++ code convention:

Ésta es una muestra de nombre de la variable:

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

string tableName; // Bad - mixed case.