11

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.

15
  • 5
    #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, 2012 at 8:52
  • 1
    @Justin I've seen macros starting with _ in popular, wide-used code, but it's definetely against the standard. Feb 17, 2012 at 8:56
  • 3
    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, 2012 at 9:13
  • 6
    Qt uses that convention exactly because smart programmers don't. It means your headers won't clash with new Qt headers.
    – MSalters
    Feb 17, 2012 at 9:14
  • 2
    You say that he (claims that he) follows Qt conventions. However, you also present his use of case and file extension as though they are totally arbitrary, inconsistent, without reason. Which is it? Surely there isn't a Qt style guide somewhere that says, "when creating a header file, roll a die and consult the following table to determine the file extension: 1: .h, 2: .hpp, 3: .H, 4: .cpp, 5: .pl, 6: none". Either there's a consistency that you're not seeing (and hence can't evaluate), or else he is not in fact following any standard convention and you can dismiss that argument immediately. Feb 17, 2012 at 9:33

7 Answers 7

19

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.

5
  • 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, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 13:49
7
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.

2
  • 1
    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, 2018 at 8:37
  • Coming back 10 years later to that question now equipped with the wisdom to answer my own question: while some of the convention choices Qt made indeed weren't ideal, Qt wasn't the problem: C++ was. It is an awful language that tries to hide his lack of established conventions with pseudo-liberty of choice. A junior shouldn't have to ask himself or herself the question : "how to name my header files?". A convention, a choice should have been made at the language design level and clearly advertised a long time ago. There are more important problems to solve.
    – ereOn
    Apr 14 at 11:46
6

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.

4
  • 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, 2012 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, 2012 at 10:27
  • Having done work with mixed C and C++ and repeatedly tripped over name mangling issues during linking, I strongly agree with using different extensions for C and C++ include files. Jul 14, 2020 at 15:38
  • Who says C++ standard header files have no extension? You can use for example <math> and the compiler will insert all the definitions that should be inserted. There is no requirement that there is a file anywhere at all. There is also no requirement whether it has an extension and which one. All you know is that if you haven’t messed up your implementation, then #include<math> will do what it is supposed to do.
    – gnasher729
    Mar 27 at 0:11
3

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.

1

@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.

0

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.

2
  • 4
    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, 2012 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. Feb 17, 2012 at 11:59
0

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.