CODEWITHSUNDEEP
c++includeheader-files
javaLover
javaLover

Reputation: 6425

Create many header files that just #include many files (act like a hub file)

It is a bad idea to stuff a lot of #include into 1 file.

My situation is a bit different - I am going to create more-than-one hub files contains only some #include:-

PhysicCommonHub.h :-

#include "PhysicCompound.h"    //~ 100 lines
#include "PhysicConstraint.h"  //~ 100 lines
#include "PhysicDummy.h"       //~ 100 lines
#include "PhysicUtil.h"        //~ 100 lines
//In real case, I include around 5 files.

GraphicCommonHub.h :-

#include "GraphicMesh.h"           //~ 100 lines
#include "GraphicLightSource.h"    //~ 100 lines
#include "GraphicUtil.h"           //~ 100 lines

My situation (and incentive) is :-

Therefore, if I am about to include PhysicCompound.h, I will just include PhysicCommonHub.h.

Advantage:-

Disadvantage:-

Question

  1. Is it worth? Is it a bad idea or a bad practice? Does it just "depend"?
    Is there such threshold (in percent) in real business?
    More specifically, is it possible that creating some hubs file is a good decision?

  2. What about using the hub-technique just for forward declaration?
    More specifically, is there any case that it is a good decision?

PhysicForwardHub.h :-

class PhysicCompound;
class PhysicConstraint;
class PhysicDummy;
class PhysicUtil;

From the close-vote, I will assume that it "depends", i.e. the answers are "yes" for both question. (?)

Upvotes: 0

Views: 55

Answers (1)

Peter
Peter

Reputation: 36597

I wouldn't just describe your approach as "bad practice". I'd describe it as terrible practice.

Practically, each one of your "hub headers" will have the same effects as described in that question you linked to.

Splitting such headers up (so there is more than one "hub header", like you describe) might mitigate some effects associated with having a single header that include a lot of other headers. However, that's not a recommendation for your approach. It is a sign of how bad a single global header is - your approach is simply less awful, rather than offering some "goodness" over alternatives.

Although you have characterised the impacts on maintainability or compilation as "a bit" (i.e. suggesting they are not significant), the reality is that the impacts are quite significant. The impacts might not be noticeable in small projects, but they are terrible in larger projects. Impacts include build times increasing by orders of magnitude, and significant lost productivity (including developers twiddling thumbs waiting for new code to compile, so they can test it).

Using the technique only for forward declarations won't gain much. There will always be code that needs complete type definitions, rather than just forward declarations. And using your "hub header" just for forward declarations will, practically, just be a thin edge of the wedge - after all, it is a small step to say "okay, I've done it for forward declarations .... now for the headers with the class definitions ....".

Realistically, although it takes some thought to decide what headers are needed in each compilation unit, that effort will normally be a small proportion of the time spent actually implementing NEW code. So what you are describing is a false economy - reduces effort thinking about your code, in a way that impacts on all sorts of productivity metrics for the project as a whole.

Upvotes: 1

Related Questions