La possession de fichiers d'en-tête C ++ sans extension est-elle une bonne pratique?

9

J'ai un argument avec un de mes collègues concernant les directives C ++ à suivre.

Il conçoit actuellement toutes ses bibliothèques de cette façon:

Il utilise des lettres majuscules et minuscules incohérentes dans ses noms de fichiers
Certains de ses en-têtes n'ont pas d'extension

Je crois que le fait de ne pas avoir d'extension est réservé aux fichiers standard C ++ et que l'utilisation de lettres majuscules est sujette aux erreurs (en particulier lorsque vous traitez avec du code qui est censé fonctionner à la fois sur Windows et Linux).

Son point est qu'il suit les Qtconventions (même pour le code qui n'utilise pas Qt) et continue de dire: "Si Qt le fait de cette façon, alors ça ne peut pas être mauvais."

Maintenant, j'essaie de garder l'esprit ouvert, mais je me sens vraiment mal quand je dois travailler sur / avec ses bibliothèques. Existe-t-il un ensemble de règles commun établi à ce sujet? La norme en dit-elle quelque chose?

Merci beaucoup.

c++ naming

— ereOn
source

3

#define signal……… («Si Qt le fait de cette façon, alors ça ne peut pas être mauvais.») - Je ne peux pas dire que je suis personnellement d'accord avec tous leurs choix de conception.

— juste le

@Justin: Moi non plus. Je n'ai rien contre Qt. Je pense même que c'est une bibliothèque incroyable, mais certains de leurs choix de conception me semblent vraiment mal.

— 2012 à 8h54

1

@Justin J'ai vu des macros commencer par _du code populaire et largement utilisé, mais c'est définitivement contraire à la norme.

— Luchian Grigore

1

mais voici une vraie raison d'éviter les en-têtes sans extensions: mon IDE principal et mon éditeur de texte ne les reconnaîtront pas automatiquement. j'utilise juste *.hpppour un en-tête c ++, et tous mes outils "l'obtiennent".

— juste le

5

Qt utilise cette convention exactement parce que les programmeurs intelligents ne le font pas. Cela signifie que vos en- têtes ne se heurteront pas aux nouveaux en-têtes Qt.

— MSalters

16

L'extension (ou son absence) ne va pas, pour autant que je sache, vous causer des problèmes. Je dirais que supprimer complètement l'extension est gênant car cela rend difficile la recherche de fichiers d'en-tête (par exemple avec les caractères génériques * .h et * .hpp) et il est plus difficile d'identifier le contenu d'un fichier (par exemple si votre éditeur s'appuie sur l'extension pour choisir le bon mode de mise en évidence de la syntaxe).

Du point de vue du code, cela ne fait pas beaucoup de différence, même le boîtier n'est pas problématique tant que vous utilisez un cas cohérent partout et ne vous fiez pas uniquement aux différences de casse pour différencier les fichiers. D'un point de vue pratique, il est plus facile de s'en tenir aux minuscules et d'avoir une extension (.h ou .hpp).

Cependant, il est plus important de choisir l'une des conventions ci-dessus pour toute votre équipe de développement et de s'y tenir . Il est bien pire de devoir rechercher comment un fichier est placé, nommé et quelle extension il utilise chaque fois que vous voulez inclure quelque chose - tout cela devrait être "devinable" en sachant ce que vous essayez d'utiliser.

— Adam Bowen
source

Choisir une convention et s'y tenir n'est pas une mauvaise idée, mais que faire si la convention existante peut être améliorée? Dans ce cas, c'est peut-être une bonne idée de modifier le cours.

— kotlinski

@kotlinski C'est l'un de ces cas où vous ne pouvez rien faire pour améliorer la situation car tout ce que vous choisissez est une question de préférence. En fait, avoir une extension, je dirais, vaut mieux que rien, car le système d'exploitation (lecture, Windows) peut déterminer le programme avec lequel ouvrir le fichier en fonction de l'extension.

— Paul

@PaulManta: Mais vous ne vous débattez pas contre vous-même ici? D'abord, vous dites qu'il n'y a aucun moyen d'améliorer quoi que ce soit. Ensuite, vous dites qu'il est préférable d'avoir une extension. C'est une sorte d'attitude défaitiste, disant qu'aucun changement n'est possible.

— kotlinski

@kotlinski En général, je suppose que cela dépend de l'ancien code avec lequel vous travailleriez, s'il serait viable de tout changer pour la nouvelle convention et quel serait l'impact des conventions de mixage. Dans ce cas, bien que je sois d'accord avec Paul Manta - c'est surtout une préférence personnelle, avec une extension étant préférée par la plupart pour des raisons pratiques.

— Adam Bowen

1

@kotlinski Il n'y a aucun moyen d'améliorer quoi que ce soit, mais il existe des moyens d'aggraver les choses. Cette discussion est aussi inutile que la discussion espaces-contre-tabulations. Choisissez simplement une convention et faites quelque chose d'utile.

— Paul

6

Il n'y a pas de règle (dans la norme) selon laquelle seuls les fichiers d'en-tête standard peuvent être sans extension; le nom de fichier peut être à peu près tout ce que vous voulez. Les bonnes pratiques générales suggèrent toutefois que:

aucun fichier ne sera jamais sans extension, et
différents types de fichiers ont des extensions différentes - en particulier, les en-têtes C ++ utilisent une extension ( .hppou .hh) différente de celle des en-têtes acceptables par un compilateur C.

(Malheureusement, la deuxième règle est souvent violée, et on voit souvent des fichiers d'en-tête C ++ avec .h. D'après mon expérience personnelle, je peux vous assurer que cela causera des problèmes de maintenance sur la route, mais c'est une pratique courante.)

En ce qui concerne la casse, une extrême prudence est requise, car les noms de fichiers sont sensibles à la casse dans certains systèmes, et pas dans d'autres. J'ai vu deux règles différentes qui fonctionnent: soit tout en minuscules dans le nom de fichier, soit le nom de fichier suit exactement les mêmes règles concernant la casse que pour les symboles en C ++.

Dans les deux cas, vous établissez des règles pour le projet, par consensus, et tout le monde les suit.

1

je suis totalement avec James sur celui-ci. Cela en fait un cauchemar d'obtenir des outils pour travailler correctement sur les 2 types différents de fichiers d'en-tête s'ils ont la même extension.

@TomTanner Et c'est encore pire si vous avez des fichiers sans extensions. J'ai surtout travaillé dans un environnement Unix, et cela m'a toujours frustré (et causé des problèmes) que les fichiers exécutables n'aient pas d'extension.

6

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

Oui. Oui, c'est vraiment, vraiment possible. Leur conception de bibliothèque est "Nous voulons tellement être Java". C'est un gâchis total. La bibliothèque Standard est bien meilleure.

En outre, fondamentalement, c'est une erreur logique. La conception de Qt ne mérite d'être émulée que si vous pouvez donner des arguments logiques sur la raison pour laquelle elle est bonne, elle n'est pas bonne simplement parce que c'est Qt.

— DeadMG
source

C'est un argument empirique. Il s'agit d'un gros produit logiciel utilisé par de nombreuses personnes. Si ce choix de convention de dénomination causait des problèmes importants, il serait connu et probablement modifié maintenant. Comme ce n'est pas le cas, cela ne peut pas être trop mauvais. Cela ne signifie pas pour autant que ce soit la meilleure solution.

— H.Rittich

0

Comme je le sais, depuis la norme 1998, seuls les en-têtes de bibliothèque standard seraient sans le .h. Ainsi, les fichiers d'en-tête C ++ non standard sont toujours conventionnellement écrits avec .h. Mais gardez à l'esprit que c'est une convention, vous ne pouvez utiliser aucune extension ni même extension .txt, c'est comme si vous écriviez vos classes en commençant par des minuscules, cela fonctionne toujours, mais ce n'est pas la convention.

— Mario Corchero
source

3

Btw "Si Qt le fait de cette façon, alors ça ne peut pas être mauvais." c'est un très mauvais argument ...

2

La norme n'a rien à dire sur la façon dont les en-têtes définis par l'utilisateur doivent être des noms. Il spécifie uniquement les noms des en-têtes standard.

— Mike Seymour

0

Ce sont des conventions et non des règles, il n'y a pas de contrainte pour adhérer aux conventions, mais les conventions rendent la vie plus facile quand vous venez pour référence.

selon les extensions (.h, .hpp), les fichiers qui ont été inclus dans le c ++ n'ont pas besoin d'extensions, vous devez utiliser les extensions si vous utilisez des en-têtes autres que c ++, comme les bibliothèques c ou les bibliothèques boost.