¿Las variables / miembros iniciales con un guión bajo desconciertan al compilador?

Me enseñaron desde la escuela secundaria que define variables como esta:

int _a;

int __a;

debe considerarse una mala práctica porque esto eventualmente desconcertará a los compiladores que usan variables que comienzan con un guión bajo para nombrar variables temporales.

Hasta donde sé, esta es la razón por la cual a algunas personas les gusta mover el guión bajo al final del nombre, como:

int a_;

Sin embargo, veo una gran cantidad de código que utiliza variables de inicio de subrayado. Y ese código se construye bastante bien con Visual Studio 2010 y g ++ 4.x.

Entonces me pregunto: ¿no es un problema hoy en día? ¿Los compiladores modernos son más inteligentes con respecto a las convenciones de nombres?

c++ programming-practices naming-standards

— Emiliano
fuente

No es una respuesta real, pero es probable que los compiladores de C ++ de Microsoft sean específicamente más indulgentes con esto porque es el estilo interno de Microsoft el uso de guiones bajos antes de las variables de miembros privados (al menos en C #). Sé que g ++ todavía puede tener problemas con los guiones bajos principales.

— KChaloux

Puede encontrar útiles las respuestas a esta pregunta .

— Blrfl

@KChaloux si cree que el equipo compilador de C ++ de Microsoft, que existe desde hace más de 20 años, estableció las reglas sobre nombres de identificadores aceptables basados en los hábitos de algunas personas en el equipo de C #, no sabe cómo funciona Microsoft :-). En serio, han pasado 21 años desde que lanzaron su primer compilador de C ++ y estas reglas se remontan hasta ese momento, o más allá en la base de código del compilador de C original.

— Kate Gregory

@Kate Solo estaba señalando que sabía a ciencia cierta que lo usaron en C #. No uso el compilador de C ++ de Microsoft, ni sé mucho sobre el entorno allí, así que deduje su uso de ese estilo de nombres en C ++ a partir de mi experiencia con C #. Nunca hice ninguna afirmación de que la regla de C # vino primero.

— KChaloux

Respuestas:

Aparentemente está malinterpretando la razón por la cual los guiones bajos del prefijo son malas prácticas. Para abreviar, es porque los estándares C y C ++ reservan estos prefijos para los detalles de implementación, por ejemplo, para la implementación estándar de la biblioteca. (tenga en cuenta que _ y __ no están reservados para las mismas cosas, ver comentarios)

Incluso si los nombres están dentro del alcance (espacio de nombres, clase, etc.), puede haber algunos nombres globales, en particular macros, que usan estos prefijos y podrían romper silenciosamente su código si los usa también.

Entonces, básicamente, la mayoría de las veces es seguro usar estos prefijos PERO si no los usa, tiene una garantía del 100% de que su nombre nunca entrará en conflicto con los nombres de implementación.

Es por eso que, en duda, no use estos prefijos.

— Klaim
fuente

sus comentarios se aplican al prefijo de dos guiones bajos pero no a un guión bajo

— Kate Gregory el

@KateGregory: los nombres con un guión bajo se reservan para que la implementación los use en el espacio de nombres global. Un guión bajo principal seguido de un segundo guión bajo o mayúscula están reservados para cualquier uso (la implementación puede usarlos para macros). Por lo tanto, un guión bajo seguido de una letra minúscula podría estar bien en los ámbitos locales, pero es mejor evitarlo para evitar tropezar y usar un nombre reservado.

— Bart van Ingen Schenau

@KateGregory: Como miembro, _limitno es un error, sino que es una función global. Creo que es mejor tener una política simple que diga "no use guiones bajos destacados, sin excepción", que una política que los permita en algunos contextos y no en otros. Pero podemos aceptar diferir en eso. Y para ser claros, no tengo problemas con guiones bajos en otros lugares que no sean el principio.

— Bart van Ingen Schenau

@BartvanIngenSchenau: solo por interés: una política simple como "usar guiones bajos destacados y solo para miembros de la clase privada" no debería conducir a problemas técnicos, ¿qué crees que es cierto?

— Doc Brown

@KateGregory Solo para aclarar, estoy de acuerdo en que las reglas son más precisas que lo que digo en mi respuesta; pero refleja la falta de precisión de mi memoria cuando trato de recordar cuáles son exactamente las reglas. Como tiendo a evitar tener que conocer las excepciones (no la función), prefiero reglas generales fáciles de seguir, en particular para reglas no tan importantes. Lo divertido es que estoy más a gusto con el movimiento semántico que recordando esto. Tal vez eso no sea divertido ahora que lo pienso ...

— Klaim

Usar dos guiones bajos es definitivamente malo, eso está reservado para los detalles de implementación específicos del compilador. Esto no se aplica al uso de un guión bajo.

Algunas personas odian los guiones bajos. Ya sea que llame algo m_indexo highest_priceo _a- que lo detestan. Trabajé con alguien hace 25 años que me habló de una impresora IBM específica (una muy popular) que se ajustaba a más líneas en la página al omitir el píxel inferior en cualquier otra línea. Esto estaba bien para los memos, o para la producción de grandes cantidades de números y demás, pero tuvo el efecto para el código de hacer invisible la mitad de sus guiones bajos. (¡Sí, de verdad!) Las personas de esa generación generalmente tienen el odio irracional de subrayado, ya sea por la interacción con esa impresora o por trabajar con alguien que los golpea y que los subrayados no deben usarse.

La mayoría de la gente encuentra el uso de mayúsculas y minúsculas (una opción que no teníamos en, por ejemplo, Fortran) un enfoque más legible: mIndex, HighestPrice, aresisten bastante bien a los ejemplos anteriormente subrayados. Te daré dos reglas:

nunca comience nada (función, variable, macro, typedef) con dos guiones bajos
elija una convención consistente (por ejemplo, _limitpara parámetros de función, m_limitpara variables miembro, nunca use guiones bajos, mayúsculas y minúsculas, escriba mayúsculas en cada palabra, húngaro, algo ) y sígala. No bop a veces con guiones bajos al principio, a veces al final, a veces sin usarlos, y cinco convenciones de carcasa diferentes. Se consistente.

La impresora en cuestión ya no existe. Si desea utilizar un guión bajo a la vez, siéntase libre de hacerlo. Pero entiendo, los que odian subrayar todavía existen.

— Kate Gregory
fuente

"Ya sea que llame a algo m_index o al precio más alto o _a, lo detestan" ¡No sin razón! No ha mencionado que existen normas en los estándares que se refieren específicamente al uso de guiones bajos en los identificadores. ¿Por qué pedir problemas cuando se evita tan fácilmente? stackoverflow.com/a/228797

— Max Barraclough

no hizo mención? Lee la primera oración de nuevo.

— Kate Gregory

"Esto no se aplica al uso de un guión bajo" no es toda la historia, vea mi enlace, que dice que liderar con guiones bajos dobles es un no-no bastante definido, pero que "Reservado en el espacio de nombres global: identificadores que comienzan con un guion bajo". ¿Por qué jugar con fuego?

— Max Barraclough

ok, te estás perdiendo el punto. El segundo párrafo trata sobre la existencia de personas que, en general, son anti-subrayado. Sin guiones bajos. Todos los guiones bajos. Sí, es cierto que además de la regla sobre dos guiones bajos, también hay una regla sobre guiones bajos seguidos de una letra mayúscula, guiones bajos a nivel mundial, etc., pero aparte de eso, algunas personas odian los guiones bajos de todos modos. Y esas personas son lo que me gusta llamar mal. No hay una razón basada en estándares para objetar guiones bajos no líderes. Pero la gente lo hace de todos modos.

— Kate Gregory

Ahí es donde no estamos de acuerdo. Sí, a veces es legal comenzar un identificador con un solo guión bajo. Como lo puse arriba, ¿por qué jugar con fuego? Nunca comienzo un identificador con un guión bajo; Lo veo como un código de olor (si se puede decir que 've' un olor :-P). De esa manera, nunca me preocupo por los detalles de las reglas que me dicen exactamente cuándo es legal hacerlo.

— Max Barraclough