4

Most often when creating multiple classes inside a program that use each other, I like to include only the minimum number of header files I need to reduce clutter.

For example, say class C inherits from class B, which contains class A. Now of course since class B contains class A as a member, it needs to include a.h in b.h. However, let's say C also needs to include a.h. Being lazy as I am, I just include b.h (which C needs to include anyways), and since b.h already includes a.h, I don't need to include anything more, and it compiles fine. Same for my .cpp files: I just include the header, and anything that's included in the header will be automatically included in my .cpp file, so I don't include it there.

Is this a bad habit of mine? Does it make my code less readable?

wrongusername
  • 18,564
  • 40
  • 130
  • 214

3 Answers3

7

I stick with this simple rule: include everything you need to completely declare a given class, but not more and make no assumptions about includes being pulled in from other sources, i.e. ensure your files are self-sufficient.

Jim Brissom
  • 31,821
  • 4
  • 39
  • 33
4

Include what's necessary for the header file to be parsed without relying on external include ordering (in other words : make your headers self-sufficient).

In your case, if c.h declares a class C which inherits from class B, obviously you must include B.h. However, if class A never appears in c.h, I believe there is no reason to include it. The fact that b.h mentions A means that b.h must make what's necessary to be parsed, either through forward declaring A or including a.h.

So from my point of view, you're doing what should be done.

Also note that if for some reasons c.h starts mentioning A, I would add the appropriate include or forward declaration so I wouldn't depend on the fact that b.h does it for me.

icecrime
  • 74,451
  • 13
  • 99
  • 111
2

It's best to include every header with definitions that you are using directly.

Relying on one of the other headers to include stuff makes your code more fragile as it becomes dependent on the implementation of classes that are external to it.

EDIT:

A short example:

  • Class B uses class A, e.g. a hash table implementation B that uses a hashing mechanism A

  • You create a class C that needs a hash table (i.e. B) and a hash algorithm (i.e. A) for some other purpose. You include B.h and leave out A.h since B.h includes it anyway.

  • Mary, one of your co-workers, discovers a paper about this new fabulous hashing algorithm that reduces the probability of collisions, while it needs 10% less space and is twice as fast. She (rightly) rewrites class B to use class D, which implements that algorithm. Since class A is no longer needed in B, she also removes all references to it from B.h.

  • Your code breaks.

EDIT 2:

There are some programmers (and I've occasionally been guilty of this too, when in a hurry) who deal with this issue by having an "include-all" header file in their project. This should be avoided, since it causes namespace pollution of unparalleled proportions. And yes, windows.h in MSVC is one of those cases in my opinion.

thkala
  • 84,049
  • 23
  • 157
  • 201