Writing Rules or Conventions and working - Header Files in C

Question

Possible Duplicate:
What are the point of header files in C?

I am working on a unix project. After searching a lot , many suggest use of header files as they are used to write code that need to be shared between several source files.

It is best to centralise the definitions in one file - Header File.

Now I got two doubts:
1) What is the significance of using header file over simply .c files.
As from this answer I get that header files are not compiled to object files. Then What happen(actually how gcc treats them)? What is the benefit? What the answer I shared want to point?

2) What are the rules or convention to write a header files. I only know this:

Header files usually ONLY contain definitions of data types, function prototypes and C preprocessor commands.

Can we write only this i.e is this is a rule or convention?

Can anyone tell me any source to learn how to write header files.

I am able to find only this -Writing Larger Programs-which does not contain much. Or any other tip or style for writing better and optimized header files.

Answer 1

1) header files allow you to pass information between .c files, e.g., definitions, or the existence of functions in other .c files, which allows you to keep code that logically belongs together in one place; the #include directive treats the named file as if it were part of the file in which it is named, which allows you to spare a lot of redundant typing

2) the convention is to pass #define's, enum's, and function declarations into .h files, with actual functional code (besides the occasional static inline function) in .c files

The rule is: whatever the compiler will eat without dying is more or less allowed, as long as it results in a functional program. The conventions exist more or less to help you keep your projects in an understandable, maintainable state.

Answer 2

I think the best is to understand why header files are useful (2) and how they work (1). Then, you can decide yourself what conventions to follow or not.

1) The "include" directive has the effect that the file pointed in the directive is completely included in the currently compiled file. This should be straightforward.

2) Generally it is easier to manage a C project split into multiple C files. This can be because of size reasons (think about projects with thousands lines of code - how can you scroll in such a file) but also for managing reasons (think about multiple people working on the project - easier to split responsibilities).

In a multiple C file project you will want to invoke functions from the other files. Let's give an example:

fileA.c
int function_a() {
  uses somewhere function_b
}

fileB.c
int function_b() {
  uses somewhere function_c 
}

fileC.c
int function_c() {
  uses somewhere function_a
}

In order to invoke any function, you need first to declare it (or define it). To be clear: a declaration is when the return type and parameters are specified, a definition is when the code is also specified. In the example above there is no way you can just "include" one C file into another such that all functions are defined before they are used. So, you have to add a "declaration" of the functions before they are called. Where can you add such a declaration? If you add a declaration of function_c in fileA.c this is very hard to maintain (think you can have this scenario over tens of files, it will be very hard to track all the declarations).

The same thing applies to types.

A solution to this problem is to create for each C file a "header" file in which you declare all the functions (and types) that are needed by other modules of the program. This files can be included in all other C files that need those functions, in any order, and are a centralized place which you know you need to modify if you change a function.