this says header files are bad design, but I don’t know why. The answers specified there are about the inefficiency of header file when building. Why it is bad design is not really touched upon.
As far as I know:
– headers lets you break the source file up so you can compile smaller things faster
– headers lets you separate the interface from the implementation
– headers lets you specify functionality in only one place. ie. no repeating
Yet using includes, include guards, headers, etc. are considered bad design. How so? What are the alternatives?
— EDIT: re. DRY issues
A common argument is that it violates DRY in that you repeat changes in signatures in both the .cpp and .h files. However, if the code is designed to reuse functionality specified in outside files, is it not unavoidable that header files must be used?
The question asks why header files are bad design, yet without the headers, is modularity not lost? If modularity is lost, is that not itself a design issue? Thus using header files averts a separate design issue.
Repeating in general is a bad idea, I get that, but it seems unavoidable if you require common functionality. In which case headers are bad, in terms of signature repetition. In terms of how you design your software, I’m inclined to say that splitting code up/modularizing, and reusing code means your code is designed well.
18
This answer looks at header files from a language design perspective. My point is not that you shouldn’t use headers in your C or C++ programs – headers are required by these languages. Instead, this answer is an argument that you shouldn’t design new languages that use header files.
Header files are bad language design, at least from a modern perspective:
-
Header files in C are a bad design not least because C’s macro system is bad: it works via token substitution, not on an AST level. This means:
- It barfs on circular includes
- It means that the same stuff is compiled multiple times
- A seemingly short and simple program might grow to a gigantic behemoth due to a few includes.
- It is incredibly limited (compared to what the gold standard of macros – Lisp – can do).
-
Header files are bad because they are files. And these files are separate from the actual code. Or not: nobody is preventing you from putting code in the header as well. Why shouldn’t the header be in the same file as the source code? There is no solid technical reason for not doing this unless single-pass compilation of each compilation unit is required.
-
Headers are bad because a non-naive compiler can jolly well figure out forward references of symbols without having these be pre-declared. Predeclarations are only useful if a multi-pass compiler is not an option for some reason. Pre-declarations have no value for a human reader (it’s a massive DRY violation), and add too little value for a compiler.
And now to refute some possible rebuttals of the “headers are bad” idea:
-
“Without headers we can’t link against libraries” – I’m sure that’s true for C and descendants (which unfortunately are ubiquitous), but this doesn’t hold for other languages.
-
A simple alternative is to directly use the source code of a library to extract the interface (this is how many scripting languages like Perl or Python kind of work).
-
This may not be desirable in closed-source environments, where the compiler output could be used to link against (which is roughly how Java works, where
.classfiles contain the interface alongside the executable bytecode).
The key point is not that no link specification exists, the key is that this specification isn’t written by humans.
-
-
“Without headers we can’t share things (functions, macros, classes) between files” – yes we can, with things like namespaces and modules containing these things. Let’s say I have a
#define PI 3.1415in some C code. To share that definition between my source files, I’d have to#include "my_math_constans.h"or something. Python’s solutionfrom math import piwhich loads themathmodule and imports thepisymbol from that module into the current scope works at least just as well.
4
Header files are a legacy of C’s heritage – it was written to be close to the hardware, but abstracted enough to run on similar platforms, if a compiler is made for the platform.
What header files do is they define symbols other files can use without the compiler having an issue. The compiler then replaces the symbolic reference with a link or copy of the actual code.
The design issue with this is that you have to repeat yourself. You define the same symbols in two separate files, and when one changes(say a method signature or a class name), the other must be changed as well.
This violates DRY – “Don’t Repeat Yourself”. This creates an automatic dependency on another file due to the header files. So then when trying to figure out what the objects and classes are doing, you need both, as there’s a tonne of syntactical knobs that can turned in either file.
9