Is having C++ header files without extension a good practice?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

The original intent was to remove the extension of the header "file" name (of the standard headers) in the C++ source file, for portability, and let the implementation supply whatever extension it wished to use for a default (.H, .hpp, .h++, .hxx, .h, or maybe something else). Remember, the standard headers need not be files, they could be objects in a database or a text library file. The compiler could see "#include <iostream>" and then open up some file which might be /usr/lib/include/c++/iostream.h or SYS$LIBRARY:IOSTREAM.HXX or whatever, or retrieve a "pre-compiled header" from a database. There was no intent for the standard to specify an actual file, let alone one with a name that didn't have an "extension". (Yes, it means the compiler needs to know something about the standard library implementation, but switches could modify that behavior like for the "include path".)

And for a non-standard header, as mentioned, the user could name the source file foo.cpp or foo.c++ or whatever the operating system allows, and name the file of declarations foo.hpp or foo.h++ or whatever. And of course foo.hpp could be referred to in the #include as just foo with the compiler applying its defaults to get the actual file name, just as you could tell the compiler to compile source file foo and the compiler (being a C++ compiler or being told it was to compile C++) would apply its defaults and open up foo.cpp or foo.c++ or whatever. (Or maybe the source code is kept in an IDE's database for the user's project and not a separate file.)

Personally, I like having extensions on files so that the editor knows what language the file is in. But that's separate from how the file is referred to in a #include.

Answer 5

@ken You are conflating header names with file names. Header names are the domain of the language/library standard, while file names are the domain of the operating system specification. The language/library implementation can use whatever mapping between the two that it desires. Some implementations may find it convenient to adopt conventions that require an extension on the actual file names (but not the header names) so that the editor or compiler can identify the language in the file. Yes, on Unix-like systems, the implementation usually stores the contents of a header in a file with the same name. But an operating system might have the convention/restriction that all actual filenames end with an extension: a dot and a limited number of letters (or alphanumeric characters).

Regardless, the inconsistencies mentioned in the OP may be confusing to the maintainers and a bad idea.

Answer 6

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.

Answer 7

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.