Now that I'd got another chance to develop a C application, whenever I crafted a header file, I always wondered whether the header file needed to include another header file such as stdio.h when there was a function prototype in my header file that spelled `FILE *'. Googling a bit for "#include in header or source file", I found this interesting thread: http://www.velocityreviews.com/forums/t316283-header-include-order.html. Reading it, I can conclude the following points:

1. Althouth the order of header inclusions should not matter, it is a good idea to lay them as follows:
a. System headers
b. Application headers
c. The header associated with this source file
because if there is a redefinition of a variable or struct or the like in (b) or (c), the compiler will point out the error to be in (b) or (c) but not in (a). Although reversing the order of inclusion to be (c), (b), and then (a) will force (c) to include any needed header, for example stdio.h when a prototype in (c) spells `FILE *', any redefinition in (b) or (c) will cause the compiler to complain about (a) instead of (b) or (c).

2. As for forcing (c) to include any needed header, there is a suggestion to not include any header file in (c) if forward declaring the needed types suffices (i.e., instead of including stdio.h, just declare `extern FILE;'). Unfortunately, this won't work for common stuff like `FILE *' or `size_t', and thinking which part can be forward-declared is just too much hassle. So, I think it is a good idea to include any necessary header file that (c) needs in (c), and include the same headers again in the source code in the order specified in (1).