Convenciones de nomenclatura variable en C ++
https://stackoverflow.com/questions/234866
-
04-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Vengo de un mundo .NET y soy nuevo en escribir C ++. Me pregunto cuáles son las convenciones de nomenclatura preferidas cuando se trata de nombrar variables locales y miembros de 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 (aunque no estoy seguro de si poner en mayúscula 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: ¿Esta (la forma anterior) sigue siendo 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!
Solución
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 correcto tipo de notación húngara es una historia diferente. )
Te sugiero que uses lo que sea que haga tu grupo. Si eres la única persona que trabaja en el programa, nómbrelos de la forma que sea más conveniente para ti.
Otros consejos
Lo más importante es ser consistente. Si está trabajando con una base de código heredada, nombre sus variables y funciones consistentemente con la convención de nomenclatura del código heredado. Si está escribiendo un código nuevo que solo interactúa con el código anterior, use su convención de nomenclatura en el nuevo código, pero sea coherente consigo mismo.
No. La "notación húngara incorrecta" - especialmente los 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 eso podría incluso ser un código válido en el hardware correcto ...).
La " notación húngara verdadera " (según lo vinculado por el jefe Geek) sigue siendo IMO 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, p. 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, al mantener el código heredado que sigue algunas convenciones de manera coherente (incluso si no lo es), debe atenerse a las convenciones que se usan allí, al menos en los módulos / unidades de compilación existentes que se deben mantener.
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 usa.
¿Qué es lo que no le gusta o se burla de " ppMyObjects " en este ejemplo, aparte de ser algo feo? No tengo opiniones fuertes de ninguna manera, pero sí comunica información útil de un vistazo que "MyObjects" no lo hace.
Estoy de acuerdo con las otras respuestas aquí. Continúe usando el estilo que se le da de la manera transmitida por razones de coherencia, o invente una nueva convención que funcione para su equipo. Es importante que el equipo esté de acuerdo, ya que está casi garantizado que cambiará los mismos archivos. Dicho esto, algunas cosas que encontré muy intuitivas en el pasado:
Las variables miembro de clase / estructura deben sobresalir: normalmente las prefijo todas con m_
Las variables globales deben sobresalir - usual prefijo con g_
Las variables en general deben comenzar con minúsculas.
Los nombres de funciones en general deberían comenzar con mayúsculas.
Las macros y posiblemente las enumeraciones deben estar en mayúsculas.
Todos los nombres deben describir lo que hace la función / variable, y nunca deben describir su tipo o valor.
Yo mismo soy una persona de notación húngara, porque encuentro que le da legibilidad al código, y prefiero el código autodocumentado a los comentarios y búsquedas.
Dicho esto, creo que puedes defender el sacrificio de tu estilo preferido y alguna capacidad de mantenimiento adicional para la unidad del equipo. No compro el argumento de la coherencia en aras de la legibilidad del código uniforme, especialmente si reduce la legibilidad para la coherencia ... simplemente no tiene sentido. Sin embargo, llevarse bien con las personas con las que trabaja puede valer un poco más de confusión sobre los tipos que miran las variables.
La notación húngara era común entre los usuarios de las API de Win32 y MFC. Si sus predecesores lo estaban usando, probablemente podría seguir usándolo (aunque sea un mal). El resto del mundo de C ++ nunca tuvo esta convención con muerte cerebral, así que no la use si está usando algo diferente a esas API.
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. En nuestra tienda, la mitad de nuestra aplicación es C ++ heredado con una nueva capa C # brillante en la parte superior (con una capa C ++ administrada 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 usted presentó. Creo que es feo, pero es consistente.
Digo, usa lo que tu equipo quiera para tu proyecto. Pero si está trabajando en código heredado o se está uniendo a un equipo, siga con el estilo que está presente para mantener la coherencia.
Todo depende de la preferencia personal. Trabajé 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 la preferencia. Mi opinión general es que el IDE debería encargarse de decirle qué tipo es, de modo que siempre que el nombre sea lo 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, la var local y el nombre constante, por lo que es fácil ver qué está sucediendo en una función y de dónde provienen los vars. Miembro: m_varName Const: c_varName local: varName
También prefiero CamelCase, de hecho, sobre todo, he visto a personas que usan CamelCase en C ++. Personalmente, no utilizo ningún prefijo para los miembros e interfaces 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 a los miembros públicos se les puede acceder directamente como en estructuras y no chocar con nombres privados. En lugar de usar guiones bajos, también he visto personas que usan la primera letra minúscula para los miembros.
struct IMyInterface {
virtual void MyVirtualMethod() = 0;
};
Las interfaces contienen 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 Manual estándar de codificación C ++ de alta integridad para obtener más inspiración.
Nuestro equipo utiliza 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.
Si usa CamelCase, la convención es poner en mayúscula la primera letra para estructuras de clases y nombres de tipos 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 los parens ya los distinguen, así que no utilizo los métodos con mayúsculas.
Personalmente no me gusta leer el código de CamelCase y prefiero subrayar minúsculas en minúsculas identificadores de datos y métodos, capitalizando tipos y reservando mayúsculas para acrónimos y el raro caso en el que uso una macro (advirtiendo que esto es una MACRO).
