¿Es una buena práctica tener archivos de encabezado C ++ sin extensión?

9

Tengo una discusión con un colega mío sobre las pautas de C ++ a seguir.

Actualmente diseña todas sus bibliotecas de esa manera:

Utiliza inconsistentemente letras mayúsculas y minúsculas en sus nombres de archivo
Algunos de sus encabezados no tienen ninguna extensión

Creo que no tener extensión es algo reservado para los archivos estándar de C ++ y que el uso de letras mayúsculas es propenso a errores (especialmente cuando se trata de código que debe funcionar tanto en Windows como en Linux).

Su punto es que sigue las Qtconvenciones (incluso para el código que no usa Qt) y sigue diciendo: "Si Qt lo hace de esa manera, entonces no puede ser malo".

Ahora trato de mantener una mente abierta, pero realmente me siento mal cuando tengo que trabajar en / con sus bibliotecas. ¿Existe un conjunto común de reglas establecidas al respecto? ¿La norma dice algo al respecto?

Muchas gracias.

c++ naming

— ereOn
fuente

3

#define signal... ... ... ("Si Qt lo hace así, entonces no puede ser malo") - No puedo decir que personalmente estoy de acuerdo con todas sus opciones de diseño.

— justin

@Justin: Yo tampoco. No tengo nada en contra Qt. Incluso creo que es una biblioteca increíble, pero algunas de sus opciones de diseño realmente me parecen incorrectas.

— antes del

1

@Justin He visto macros que comienzan con un _código popular y ampliamente utilizado, pero definitivamente está en contra del estándar.

— Luchian Grigore

1

pero aquí hay una razón real para evitar encabezados sin extensiones: mi IDE principal y el editor de texto no los reconocerán automáticamente. Solo lo uso *.hpppara un encabezado c ++, y todas mis herramientas "lo entiendo".

— justin

55

Qt usa esa convención exactamente porque los programadores inteligentes no lo hacen. Significa que sus encabezados no chocarán con los nuevos encabezados Qt.

— MSalters

16

La extensión (o falta de) no va a, por lo que sé, causarle problemas. Diría que descartar la extensión por completo es inconveniente ya que dificulta la búsqueda de archivos de encabezado (por ejemplo, con los comodines * .h y * .hpp) y hace que sea más difícil identificar el contenido de un archivo (por ejemplo, si su editor confía en la extensión para elegir el modo de resaltado de sintaxis adecuado).

Desde el punto de vista del código, no hace mucha diferencia, incluso la carcasa no es problemática siempre que use un caso coherente en todas partes y no confíe solo en las diferencias de casos para diferenciar los archivos. Desde el punto de vista de la conveniencia, es más fácil quedarse con minúsculas y tener una extensión (ya sea .h o .hpp).

Sin embargo, es más importante que cualquiera de los anteriores es elegir una convención para todo su equipo de desarrollo y cumplirla . Es mucho peor tener que buscar cómo se encajona un archivo, qué nombre se usa y qué extensión usa cada vez que desea incluir algo; todo esto debe ser "adivinable" con conocimiento de lo que está tratando de usar.

— Adam Bowen
fuente

Elegir una convención y apegarse a ella no es una mala idea, pero ¿y si la convención existente se puede mejorar? En ese caso, tal vez sea una buena idea alterar el curso.

— kotlinski

@kotlinski Este es uno de esos casos en los que no hay nada que pueda hacer para mejorar la situación porque cualquier cosa que elija es una cuestión de preferencia. En realidad, tener alguna extensión, diría, es mejor que ninguna, porque el sistema operativo (lectura, Windows) puede determinar con qué programa abrir el archivo en función de la extensión.

— Paul

@PaulManta: ¿Pero no estás discutiendo contra ti mismo aquí? Primero, dices que no hay forma de mejorar nada. Entonces, dices que tener una extensión es mejor que no. Esa es una especie de actitud derrotista, que dice que no hay cambio posible.

— kotlinski

@kotlinski En general, supongo que eso depende de la cantidad de código antiguo con el que estaría trabajando, si sería viable cambiarlo todo a la nueva convención y cuál sería el impacto de mezclar convenciones. En este caso, aunque estoy de acuerdo con Paul Manta, es principalmente una preferencia personal, y la mayoría prefiere una extensión por razones prácticas.

— Adam Bowen

1

@kotlinski No hay forma de mejorar nada, pero hay formas de empeorar las cosas. Esta discusión es tan inútil como la discusión de espacios vs pestañas. Simplemente elige una convención y ve a hacer algo útil.

— Paul

6

No hay una regla (en el estándar) que solo los archivos de encabezado estándar pueden estar sin una extensión; el nombre del archivo puede ser casi todo lo que quieras. Sin embargo, las buenas prácticas generales sugieren que:

nunca hay archivos sin una extensión, y
diferentes tipos de archivos tienen diferentes extensiones, en particular, los encabezados de C ++ usan una extensión ( .hppo .hh) diferente que los encabezados que son aceptables para un compilador de C.

(Lamentablemente, la segunda regla a menudo se viola, y a menudo se ven archivos de encabezado C ++ .h. Por experiencia personal, puedo asegurar que esto causará problemas de mantenimiento en el futuro, pero es una práctica común).

Con respecto al caso, se requiere un cuidado extremo, ya que los nombres de archivo distinguen entre mayúsculas y minúsculas en algunos sistemas, y no en otros. He visto dos reglas diferentes que funcionan: o todo en minúsculas en el nombre del archivo, o el nombre del archivo sigue exactamente las mismas reglas con respecto a mayúsculas y minúsculas que para los símbolos en C ++.

En ambos casos, usted establece reglas para el proyecto, por consenso, y todos las siguen.

1

Estoy totalmente con James en este caso. Es una pesadilla que las herramientas funcionen adecuadamente en los 2 tipos diferentes de archivos de encabezado si tienen la misma extensión.

@TomTanner Y es aún peor si tienes archivos sin extensiones. Trabajé principalmente en un entorno Unix, y siempre me ha frustrado (y causado problemas) que los archivos ejecutables no tengan una extensión.

6

If Qt does it that way, then it can't be bad.

Si. Sí, realmente puede. El diseño de su biblioteca es "Tenemos muchas ganas de ser Java". Es un desastre total. La biblioteca estándar es mucho mejor.

Además, fundamentalmente, es una falacia lógica. El diseño de Qt solo vale la pena emular si puedes dar argumentos lógicos sobre por qué es bueno, no es bueno solo porque es Qt.

— DeadMG
fuente

Es un argumento empírico. Es un gran producto de software que utilizan muchas personas. Si esta elección de la convención de nomenclatura causara problemas importantes, ya se conocería y probablemente cambiaría. Como este no es el caso, no puede ser tan malo. Sin embargo, eso no significa que sea la mejor solución.

— H. Rittich

0

Como sé, desde el estándar de 1998, solo los encabezados de la biblioteca estándar estarían sin .h. Por lo tanto, los archivos de encabezado C ++ no estándar todavía se escriben convencionalmente con .h. Pero tenga en cuenta que es una convención, no puede usar ninguna extensión o incluso la extensión .txt, es como si escribiera sus clases comenzando con minúsculas, todavía funciona, pero no es la convención.

— Mario Corchero
fuente

3

Por cierto "Si Qt lo hace así, entonces no puede ser malo". es un argumento muy malo ...

2

El estándar no tiene nada que decir sobre cómo los encabezados definidos por el usuario deben ser nombres. Solo especifica los nombres de los encabezados estándar.

— Mike Seymour

0

Estas son convenciones, no reglas, no hay restricciones para adherirse a las convenciones, pero las convenciones hacen la vida más fácil cuando se busca referencia.

según las extensiones (.h, .hpp), los archivos que se han incluido en c ++ no necesitan tener extensiones, debe usar las extensiones si está usando encabezados que no sean c ++, como las bibliotecas de c o las bibliotecas de impulso.