0

Suppose I have a code like this

foo.h

#pragma once #ifndef _HEADER #define _HEADER //code #endif

foo.c

#include "header.h" //code

main.c

#include "foo.h" int main() { return 0 }

Why should I include foo.h in foo.c? It can still work without it.

Improve this question
5
  • 1
    Generally, foo.h would declare the interface defined in foo.c that other modules, like main.c, will use. That would mean function prototypes, etc. By including foo.h into foo.c, it will be a nice defensive check that foo.h and foo.c are consistent. The compiler will throw a warning or error if they are not. Commented Jan 3, 2015 at 14:24
  • 3
    Sure, C doesn't require it. You'll eventually discover that the ability of the compiler to tell you that there's a mismatch between the declaration and the call of the function is very useful. A lesson that needs to be learned in the School of Hard Knocks, second year. Commented Jan 3, 2015 at 14:34
  • 1
    Also, the prototypes are useful if you need to call other functions, since without prototypes C would require you to define functions in the order of dependency (and prevents mutually dependent functions). Commented Jan 3, 2015 at 14:35
  • It is a convention, not a requirement. You could code without any header files (by copy & pasting code chunks) but that would be inconvenient Commented Jan 3, 2015 at 14:42
  • It allows you to define an API by grouping all your functions definitions in one place. This encourages modularization of code, and makes things easier for other programmers looking at your code. It also makes your code more easily extendible. Commented Jan 3, 2015 at 17:36

1 Answer 1

Reset to default
5

You are correct that you do not HAVE to include the module's header file in the module's C file.

There are a few reasons why you may wish to do so. (What follows is a non-exhaustive list).

  1. As others have noted, it helps ensure that the declarations in the header file are consistent with the definitions in the C file. This is of particular importance when some or all of the routines are to be called from another module. In other words, this can help cut down on errors.

  2. It safely and quickly allows you a little extra flexibility in where you place the routines in the file. Granted this can be achieved with forward declarations in the C file, but if the routines are going to be called from another module, then save yourself the extra typing (and possible typos) and make use of the header file inclusion. Why would you want the flexibility? It allows you to group the routines as you see fit for both maintainability and readability.

  3. It helps to keep your list of include files leaner and cleaner. Presumably, your module's header file will include anything that it needs. Therefore, including that header file means that you don't have to explicitly include all those extra header files. Experience has taught me that a modules with lean include lists often have fewer WTF moments (as well as having a very small positive impact on compilation time).

Hope this helps.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Reason 1. is the crucial one, and I daresay that one is enough to strongly encourage the inclusion of the module header. I would never accept source code in a project that fails to include the corresponding headers for precisely that reason.