I've read repeatedly that header files should include all the declarations that other files will need to use the source code. Suppose then that you have a function that is not used directly by other source files (a non-interface function, in other words). Should its prototype be placed at the top of the .c file, since it will not be used by other files? Or should it be placed in the header files with all the other functions, in order to fully summarize the functions present in the .c file in one place?
Asked
Active
Viewed 2,013 times
5 Answers
5
The header contains the interface information (whatever is needed for the outside world to use the functionality in the "module" -- e.g. the .c file). So internal functions (that are not used from outside), do not go into the header
In the .c file it depends on organization
- some people like to list all internal function declaration at the top, so they are in one place.
- others rely on ordering so a function is defined by the time it is used (in another function); and only forward declare it if necessary (e.g. recursive functions that call each other)
Attila
- 28,265
- 3
- 46
- 55
4
If the function is not used by other .c files, it should not have a prototype in a header file. You should give it the static modifiler, and place the prototype at the top of the (only) .c file where it is used.
If it's reasonable and possible, you can just define the function before all the functions that call it, so you don't even need a prototype.
3
Yes, the prototype of a private function should be placed in the same .c file as the function. The header defines the external interface.
Rather than forward declarations, some programmers prefer to define the functions in the order they're used so prototypes are unnecessary. Of course, you can't do this if two or more functions call each other.
My personal preference is to declare all of the functions first, so you'll have an overview of the file.
If you have functions that are used within a single module (a small set of files that together implement a functional unit), it's perfectly reasonable to create a second module-specific header file. All of the files in the module—but no external source files—will #include it.
Adam Liss
- 47,594
- 12
- 108
- 150
0
Given that header files are essentially the only way to declare an external interface in C, things not part of that interface should not be in the header file.
C being what it is, sometimes this is not practical, because the internal view of an externally visible definition needs to refer to it; in this case you might place it in the header but protected by a #define that clearly indicates its internal provenance, and likewise use #ifdef to select the internal vs. external version of the definition that requires it. (You will see this in system header files often.) It's better to try to avoid this, though.
geekosaur
- 59,309
- 11
- 123
- 114
0
Putting at all the function declarations in the prototype syntax at the top of the .c source file is good style in my opinion. It serves also to document you source code for the reader.
You don't want to put the declarations in the .h header file as you would unnecessarily expose the internals of your programs.
Oh, and don't forget to add the static specifier in the function declarations.
ouah
- 142,963
- 15
- 272
- 331