nombres - ¿Cómo se concilian las convenciones comunes de nomenclatura de C++ con las de las bibliotecas?
nombrado de variables métodos y constantes (10)
La mayoría de las convenciones de nombres de C ++ dictan el uso de camelCaseIdentifiers : nombres que comienzan con una letra mayúscula para las clases ( Person , Booking ) y nombres que comienzan con una letra minúscula para campos y variables ( getPrice() , isValid() , largestValue ). Estas recomendaciones están completamente en desacuerdo con las convenciones de nomenclatura de la biblioteca C ++, que incluyen nombres en minúsculas para clases ( string , set , map , fstream ) y names_joined_with_an_underscore para métodos y campos ( find_first_of , lower_bound , reverse_iterator , first_type ). Una complicación adicional de la imagen son las funciones del sistema operativo y de la biblioteca C, que implican nombres en minúscula comprimidos en C y Unix y funciones que comienzan con una letra mayúscula en Windows.
Como resultado, mi código es un desastre, porque algunos identificadores usan la biblioteca C ++, C o la convención de nombres de sistemas operativos, y otros usan la convención prescripta de C ++. Escribir clases o métodos que envuelvan la funcionalidad de la biblioteca es doloroso, porque uno termina con nombres de diferentes estilos para cosas similares.
Entonces, ¿cómo concilias estas diferentes convenciones de nombres?
¿Por qué la necesidad de reconciliarse? Siempre que compile el código y pueda realizar el trabajo, no se preocupe.
Bueno, dado que no podemos cambiar la forma en que se implementan las bibliotecas estándar, creo que tendremos que vivir con eso. En cuanto a la conciliación, mientras escribía algunas API de Win32 hace un tiempo, traté de nombrar mis propios métodos en PascalCasing como se hace en la API, pero simplemente no me sentía bien. Así que volví a nombrar mis métodos en camelCase. Estoy de acuerdo en que es un desastre, pero la otra opción es adaptar su estilo a cada nuevo marco o biblioteca que use, y luego está el problema de que menciona tener más de una biblioteca usando diferentes convenciones en un solo proyecto. Así que mi consejo es: apegarse a lo que se sienta bien para sus propios métodos y clases. O bien, cuando se encuentre en un entorno corporativo, cumpla con las mejores prácticas y directrices de su empresa.
Cita favorita ::
¡Lo mejor de los estándares es que hay tantos para elegir!
Mi sugerencia sería tomar la convención de la biblioteca que ocurre más a menudo en el código de su empresa (probablemente la biblioteca C ++, que creo que también se aplica a los impulsores) y convertirla en su estándar. De lo contrario, es mejor que no tengas uno.
Diomidis, comparto tu dolor y he pasado mucho tiempo cambiando entre diferentes esquemas a lo largo de los años, tratando de encontrar algo que funcione con las diferentes bibliotecas / frameworks que uso (MFC y / o STL / Boost). Al trabajar con un único marco, como el STL, puede intentar copiar la convención de nomenclatura que utiliza, pero cuando introduce un marco diferente, se desmorona fácilmente.
Al final, he adoptado un estilo único para todos los códigos nuevos que escribo (según las pautas de estilo de Google C ++) y refactorizo el código anterior para usar este estilo cuando corresponda. No puede conciliar las diferentes convenciones de nombres muy fácilmente, así que no pierda el tiempo intentando. Haga cumplir un esquema para su equipo / departamento / compañía y cúmplalo, pero no se obsesione con lo "feo" que puede parecer el código cuando usa una combinación de esquemas.
Las directrices de Google C ++ son bastante buenas en mi humilde opinión, con algunas modificaciones menores. Consulte la guía aquí:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
En los proyectos en los que trabajo, sigo las convenciones de código para mi proyecto. Cuando llamo a algo diferente, utilizo API de esa biblioteca.
También agregaría que el ajuste de la biblioteca es una mala idea (hay muchos en la base de código en la que estoy trabajando) porque generalmente lo hace el desarrollador que resuelve su problema y, por lo general, no es apropiado para su uso. por todos los otros desarrolladores. Del otro lado, la envoltura de alta calidad es costosa.
Honestamente, usaría la biblioteca tal como está y me apegaré a tu propio estilo de codificación. Podrías envolverlo, pero eso parece exagerado.
Me parece recordar haber leído hace mucho tiempo que eligen hacer la biblioteca estándar diferente de la convención de codificación recomendada a propósito, para evitar nombrar colisiones. Sin embargo, no puedo encontrar ninguna referencia que mencione eso ahora. Recuerdo haber leído que no debes usar letras minúsculas en los nombres de tipo porque estaban reservadas para las bibliotecas estándar. Supongo que algo similar está sucediendo con el uso de caracteres de subrayado. Realmente no veo las convenciones de nomenclatura múltiples como un problema, ya que claramente separa el código estándar del código en su proyecto. Siempre codifico cosas en mis proyectos utilizando mayúsculas y mayúsculas para tipos y camello inferior para métodos / miembros. Mi lugar de trabajo actual utiliza mayúsculas y mayúsculas para los métodos además de los tipos, lo que me molesta mucho. Pero, también les gustan las verrugas húngaras, que incluso MS ha desheredado: P
Tiendo a ser un perfeccionista cuando se trata de estilo de código, y esto siempre me ha molestado. Ojalá hubiera un estándar universal, pero no lo hay. En mi carrera profesional, he descubierto que mientras los programadores en un proyecto individual sean consistentes, eso es lo mejor que puedes esperar.
En última instancia, creo que se trata de saber de qué biblioteca proviene un método, objeto o función. Si lo sabe, entonces será más fácil recordar qué convención utiliza esa biblioteca, suponiendo que el proyecto no incluya muchas bibliotecas. He intentado adaptar mi propio código para que coincida con el de las bibliotecas que uso, pero siempre es un objetivo en movimiento y frustrante al final.
Deberías abrazar la diferencia.
Cuando las personas vean el uso de remove_copy_if, inmediatamente sabrán que se trata de un algoritmo. Esto es en realidad una característica positiva ya que los algoritmos vienen con ciertas garantías (o falta de).
También utilizamos la convención de nomenclatura para nuestros propios algoritmos personalizados.
Una forma de adoptar la naming_convention C ++, esto es lo que hacen la mayoría de los ejemplos de código en la literatura actual.
Poco a poco veo estas convenciones pasar al código de producción, pero es una batalla contra las convenciones de nombres de MFC que aún prevalecen en muchos lugares.
Otras diferencias de estilo que luchan contra los viejos estándares son el uso de guiones bajos en lugar de m_ para denotar miembros.