Cómo conciliar las convenciones de nomenclatura comunes de C++ con las de las bibliotecas

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). Cuando se trabaja con un único framework, como el STL, se puede intentar copiar la convención de nomenclatura que utiliza, pero cuando se introduce un framework diferente, se desmorona fácilmente.

Al final he adoptado un estilo único para todo el código nuevo que escribo (basado en las pautas de estilo de Google C++) y refactorizo código antiguo para usar este estilo cuando sea apropiado. No puede conciliar las diferentes convenciones de nomenclatura muy fácilmente, así que no pierda tiempo intentándolo. Aplique un esquema para su equipo / departamento./ company y apégate a ella, pero no te quedes colgado de lo 'feo' que puede verse el código cuando usas una mezcla de esquemas.

Las directrices de Google C++ son bastante buenas en mi humilde opinión, con algunas modificaciones menores. Echa un vistazo a la guía aquí:

Http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

¿Por qué la necesidad de reconciliarse? Siempre y cuando el código se compile, y se puede hacer el trabajo, no se preocupe por ello.

Tiendo a ser un perfeccionista cuando se trata de estilo de código, y esto siempre me ha molestado. Desearía que hubiera un estándar universal, pero no lo hay. En mi carrera profesional, he encontrado 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 sabes eso, entonces se vuelve bastante fácil recordar qué convención es utilizado por esa biblioteca, asumiendo que el proyecto no incluye 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 simplemente frustrante al final.

Fav cita::

Lo mejor de los estándares es que hay muchos para elegir!

Mi sugerencia sería tomar la convención de la biblioteca que ocurre en el código de su empresa con mayor frecuencia (probablemente la biblioteca C++, a la que creo que boost también se adhiere), y hacer que su estándar. De lo contrario, también podría no tener uno en absoluto.

En los proyectos en los que estoy trabajando sigo las convenciones de código para mi proyecto. Cuando llamo a otra cosa utilizo la API de esa biblioteca.

También agregaría que envolver la biblioteca es una mala idea (hay muchos de ellos en el código base en el que estoy trabajando) porque generalmente lo hace el desarrollador que resuelve su propio problema y, por regla general, es inapropiado para el uso de todos los demás desarrolladores. Desde el otro lado, el embalaje de alta calidad es caro.

Bueno, ya que no podemos cambiar la forma en que se implementan las bibliotecas estándar, supongo que tendremos que vivir con ello. En cuanto a la reconciliación, mientras escribía algunas cosas de la API de Win32 hace un tiempo, intenté nombrar mis propios métodos en PascalCasing como se hace en la API, pero simplemente no me sentí 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 que menciona tener más de una biblioteca usando diferentes convenciones en un solo proyecto. Así que mi consejo es-se adhieren a lo que se siente bien para sus propios métodos y clases. O, cuando se encuentre en un entorno corporativo, siga las mejores prácticas y directrices de su empresa.

Me parece recordar haber leído hace mucho tiempo que optaron por hacer que la biblioteca estándar sea diferente de la convención de codificación recomendada a propósito, para evitar colisiones de nombres. Sin embargo, no puedo encontrar ninguna referencia que mencione eso ahora. Recuerdo haber leído que no debería usar letras minúsculas iniciales en los nombres de tipo porque estaban reservados para las bibliotecas estándar. Supongo que algo similar está pasando con el uso de guiones. Realmente no veo varias convenciones de nombres como un problema, ya que separa claramente el código estándar del código en su proyecto. Siempre codifico cosas en mis proyectos usando capital camel case para tipos y lower camel case para métodos / miembros. Mi lugar de trabajo actual utiliza capital camel case para métodos además de tipos, lo que me molesta mucho. Pero, también les gustan las verrugas húngaras, que incluso MS ha repudiado: P

Honestamente, solo usaría la biblioteca tal cual y me apegaría a su propio estilo de codificación. Usted podría envolverlo, pero eso parece exagerado.

Deberías aceptar la diferencia.

Cuando la gente vea el uso de remove_copy_if, inmediatamente sabrán que esto es un algoritmo. Esto es realmente una característica positiva ya que los algoritmos vienen con ciertas garantías (o falta de).

También usamos la convención de nomenclatura para nuestros propios algoritmos personalizados.