I have an argument with a collegue of mine regarding the C++ guidelines to follow.

He currently designs all his libraries that way:

  • He uses inconsistently uppercase and lowercase letters in his filenames
  • Some of his headers don't have any extension

I believe that having no extension is something reserved for C++ standard files and that using uppercase letters is error prone (espcially when you deal with code which is meant to work on both Windows and Linux).

His point is that he follows Qt conventions (even for code that doesn't uses Qt) and keep saying : "If Qt does it that way, then it can't be bad."

Now I try to keep an open-mind, but I really feel bad when I have to work on/with his libraries. Is there a common established set of rules regarding this ? Does the standard tell something about it ?

Thank you very much.

  • 3
    #define signal … … … ("If Qt does it that way, then it can't be bad.") - I can't say I personally agree with all their design choices. – justin Feb 17 '12 at 8:52
  • @Justin: Neither do I. I have nothing against Qt. I even think it is an amazing library but some of their design choices really feels wrong to me. – ereOn Feb 17 '12 at 8:54
  • 1
    @Justin I've seen macros starting with _ in popular, wide-used code, but it's definetely against the standard. – Luchian Grigore Feb 17 '12 at 8:56
  • 1
    but here's one real reason to avoid headers without extensions: my primary IDE and text editor will not recognize them automatically. i just use *.hpp for a c++ header, and all my tools "get it". – justin Feb 17 '12 at 9:13
  • 5
    Qt uses that convention exactly because smart programmers don't. It means your headers won't clash with new Qt headers. – MSalters Feb 17 '12 at 9:14

The extension (or lack of) isn't going to, as far as I know, cause you issues. I would say that dropping the extension altogether is inconvenient as it makes it difficult to search header files (for example with the wildcards *.h and *.hpp) and it makes it more difficult to identify the contents of a file (for example if your editor relies on the extension to choose the proper syntax highlighting mode).

From a code point of view it doesn't make much difference, even the casing is not problematic so long as you use a consistent case everywhere and don't rely on case differences alone to differentiate files. From a convenience point of view it's easier to stick to lower case and have an extension (either .h or .hpp).

More important that any of the above, however, is to pick one convention for your entire development team and stick to it. It is far worse to have to look up how a file is cased, named and what extension it uses whenever you want to include something - all of these should be "guessable" with knowledge of the thing you are trying to use.

  • Picking one convention and sticking to it is not a bad idea, but what if the existing convention can be improved? In that case, maybe it is a good idea to alter the course. – kotlinski Feb 17 '12 at 9:09
  • @kotlinski This is one of those cases where there's nothing you can do to improve the situation because anything you pick is a matter of preference. Actually, having some extension, I'd say, is better than none, because the OS (read, Windows) can determine what program to open the file with based on the extension. – Paul Feb 17 '12 at 9:12
  • @PaulManta: But aren't you arguing against yourself here? First, you say that there is no way to improve anything. Then, you say having an extension is better than not. That is a kind of defeatist attitude, saying that no change is possible. – kotlinski Feb 17 '12 at 10:19
  • @kotlinski In general, I guess that depends how much old code you would be working with, whether it would be viable to change it all to the new convention and what the impact of mixing conventions would be. In this case though I agree with Paul Manta - it's mostly personal preference, with an extension being preferred by most for practical reasons. – Adam Bowen Feb 17 '12 at 10:21
  • 1
    @kotlinski There's no way to improve anything, but there are ways to make things worse. This discussion is as pointless as the spaces-vs-tabs discussion. Just pick one convention and go do something useful. – Paul Feb 17 '12 at 13:49

There is no rule (in the standard) that only standard header files can be without an extension; the filename can be pretty much anything you want. General good practice, however, suggests that:

  1. no files ever be without an extension, and

  2. different types of files have different extensions—in particular, C++ headers use a different extension (.hpp or .hh) than headers that are acceptable to a C compiler.

(Regretfully, the second rule is often violated, and one often sees C++ header files with .h. From personal experience, I can assure that this will causes maintenance problems down the road, but it is common practice.)

With regards to case, extreme care is required, since filenames are case sensitive in some systems, and not in others. I've seen two different rules which work: either everything in lowercase in the filename, or the filename follows exactly the same rules regarding case as for symbols in C++.

In both cases, you establish rules for the project, by consensus, and everyone follows them.

  • 1
    i'm totally with James on this one. It makes it a nightmare getting tools to work appropriately on the 2 different sorts of header files if the have the same extension. – Tom Tanner Feb 17 '12 at 9:52
  • @TomTanner And it's even worse if you have files without extensions. I've mostly worked in a Unix environment, and it's always frustrated me (and caused problems) that executable files don't have an extension. – James Kanze Feb 17 '12 at 10:27
If Qt does it that way, then it can't be bad.

Yes. Yes, it really, really can. Their library design is "We so badly want to be Java". It's a total mess. The Standard library is much better.

Also, fundamentally, it's a logical fallacy. Qt's design is only worth emulating if you can give logical arguments about why it's good, it's not good just because it's Qt.

  • It is an empirical argument. It is a big software product that is used by many people. If this choice of naming convention caused significant problems, it would be known and probably changed by now. As this is not the case, it cannot be too bad. That does not mean that it is the best solution, though. – H. Rittich Sep 18 '18 at 8:37

As I know, since 1998 standard, only standard library headers would be without the .h. So non-standard C++ header files are conventionally still written with .h. But bear in mind that it's a convention, you can use no extension or even .txt extension, it is like you write your classes starting with lower case, it's still working, but it's not the convention.

  • 3
    Btw "If Qt does it that way, then it can't be bad." it's a really bad argument... – Mario A. Corchero Jiménez Feb 17 '12 at 8:57
  • 2
    The standard has nothing to say about how user-defined headers should be names. It only specifies the names of the standard headers. – Mike Seymour Feb 17 '12 at 11:59

These are conventions not rules there is no constraint to adhere to conventions,but conventions do make life easier when u come around for reference.

as per the extensions(.h,.hpp) those files which have been included in the c++ need not have extensions, u need to use the extensions if you are using headers from other than c++,like c libraries or boost libraries.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.