Separating the Interface and Implementation in C - c

Question

In separating the interface from implementation in C, where is the right place to include a header file?
In the interface file (.h file) or in the implementation file (.c file)? Why?
My Sample Code:
console.h
#ifndef CONSOLE_H
#define CONSOLE_H
#include <windows.h>
void gotoxy (const WORD x, const WORD y);
void clearScreen();
#endif
console.c
#include <stdlib.h>
#include "console.h"
COORD coord = {0,0};
void gotoxy (const WORD x, const WORD y){
coord.X = x;
coord.Y = y;
SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE), coord);
}
void clearScreen(){
system("cls");
}

Answer 1

Here are some principles:
An unnecessarily included header only adds to the compilation time.
This may sound ignorable, and it generally is, but if you get into the habit of including too much, it can become an issue.
Imagine you have a general header for your project, that includes all other project headers and all the system headers they may need. So any .c file only needs to include this one header and be done with it. This is convenient. However, apart from prolonging the compilation of each .c file a bit, it also guarantees that you have to recompile the entire project every time you change a single header. And that will significantly slow down your modify-compile-test cycle.
You must avoid creating circular include dependencies.
If you do create a circular include, you are in for trouble. So, best avoid including anything unnecessary: the less you include, the less headers can trigger circular includes. Sometimes you may be required to insert a forward declaration instead of an include.
A .c file must include its .h file.
If you fail to do this, the function signatures in the .c file won't be checked against the declarations in the .h file, and madness will follow.
The problem with this principle is, that your .c file may compile fine without the include if the .h file does not define a type that is needed by the implementation. Nevertheless, the include must be there to prevent signature mismatches.
So, apart from point 3, it is prudent to only include headers that are absolutely needed, and only in the file that actually needs it. Personally, I frequently only include a header after I get a compiler error telling me that something is missing.

Answer 2

Include directives should always be included in the file that needs them, or to make reading and understanding your code easier.
In your example, you include windows.h inside console.h. For such a common header file, it'd be fine to leave it in console.h only. However, if you were using another library that you'd written, and was not already widely adopted, it would be wise to include it in both files to prevent future developers from having to hunt through header files searching for the one which provided functionality seen in console.c.

Answer 3

There are only two changes to your setup I would make. I would include all headers in the header file except for the console.h header which is necessary to include the header. Second, when you #define CONSOLE_H 1, give it a value 1 is fine. I just prevents an uninitialized tag. Looks good.
console.h
#ifndef CONSOLE_H
#define CONSOLE_H 1
#include <windows.h>
#include <stdlib.h>
void gotoxy (const WORD x, const WORD y);
void clearScreen();
#endif
console.c
#include "console.h"
COORD coord = {0,0};
void gotoxy (const WORD x, const WORD y){
coord.X = x;
coord.Y = y;
SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE), coord);
}
void clearScreen(){
system("cls");
}

Answer 4

Like it was already mentioned in comments and other answers - includes should be in the file that needs them.
However, for complex/large projects, I'd recommend to design the interfaces such that they require only handlers/references to actual data instead of actual data. This allows usage of forward declarations in header files and actual includes in the implementation files. The reason for this is avoidance of tight coupling. Tight Coupling often leads to very problematic behavior, forcing to include headers that aren't directly needed (and even creating circular dependencies, resulting in compilation failures and need for extensive changes!), increasing compilation time and harming such SW quality attributes as modularity, maintainability and scalability.
That said, there are common headers (usually part of the environment you're using) that are needed in most situations (e.g., stdio.h, windows.h etc.) - including these won't hurt the SW quality although the compilation time might still increase. One way to deal with this is to use Precompiled headers.