Which comes first? header guards, namespace and includes [closed]

Question

I have been making files like this for awhile: Does the order make sense? or should the namespace and the #includes be swapped and why.

#ifndef CLASSNAME_H // header guards
#define CLASSNAME_H

#include "a.h" // includes in alphabetical order
#include "b.h" // user specified includes first
#include "c.h"
#include <vector> // then library includes

namespace MyNamespace
{
    class ClassName
    {

    };
}

#endif

Lankton

Just imagine that #include literally pastes the file contents into your base file, and then work out in which namespace you want to have which declarations. – Joni

... and also consider what would happen if different .cpp files included the same headers inside different namespaces... – Platinous

Answer 1

Yes. That's looks good.

Though I order my headers differently (but alphabetically is fine).

The only thing I would change is the include guard. I make the include my namspace as well as the class name. As several times I have classes with the same name (but in a different namespace) being used by the same code.

#ifndef MY_COMPANY_MY_NAME_SPACE_MYCLASSNAME_H // header guards
#define MY_COMPANY_MY_NAME_SPACE_MYCLASSNAME_H

#include "a.h" //   includes in order of most specific to most general.

               //   My includes first.
               //   Then C++ headers          <vector>
               //        I group all the containers together.
               //   Then C specific headers   <sys/bla.h>
               //   Then C generic headers    <ctype.h>


namespace MyNamespace
{
    Class ClassName
    {

    };
}

#endif

Kimura

When header file names are unique, using the same name for the include guard is sufficient; this is the typical case. If you were pulling include files from different directories you might have two with the same name, then this technique might make sense. – Muss

The problem with this rule is that you have to argue with other devs which includes are "more specific" and which are "more general". So, since every include should pull all of its dependencies, the order is generally irrelevant, and alphabetical order is a good choice that causes no discussion (after you split project and system headers, of course). – Quoth

It depends on what you're doing. If you're working on an application, just MYFILE_H should be fine, as long as you ensure that all of the filenames are unique. If you're working on a library that will be used in unknown contexts, you'll definitely want to protected it more: I use something like: GB_Fallible_hh_20061203izn6Lk4kky3qvxlFVfxSpKam: the last 24 characters are randomly generated (using /dev/random), which means that conflicts are impossible. – Outfoot

@JamesKanze, Microsft C++ would add a GUID to the include guard if you let its wizard generate the file for you; don't know if that's still true or not. – Muss

@James Kanze: AS Mark said DevStudio will do this for you. If you want to do it manually there is an application as part of the dev tools that will generate a guid for non MS people you can get a GUID on the web somacon.com/p113.php – Kimura

Why not just include the library name in the guard? Easy, descriptive and hard to imagine this to make a problem in reality.. – Disorderly

@Disorderly I've already encountered two libraries with the same name. Since the name of the library generally appears in the namespace, etc., you're likely to get other conflicts as well (although I mangle in a version into the namespace as well, to ensure that you can't compile with the headers of one version, and link with those of another), why take the risk. You never actually write the name that appears in the header guard---it's generated automatically when you open a new header file, and you don't refer to it otherwise. – Outfoot

Answer 2

What you've written is perfect. I don't think you need to change the order.

Forcer