This thread itself might be arbitrary, but I thought of something today that I think will help QC my libraries.
Before today I thought (not too long, though) that #include
order was pretty much arbitrary. To make sense of them, as some of my sources have 30 or so, I generally used this pattern:
#include "header corresponding to this source"
#include <C++ system headers>
#include <POSIX/Linux C system headers>
#include "this library's own API headers"
#include "local headers"
While this makes sense to me and eases my angst for orderly files, aside from the corresponding header, I honestly thought there wasn't any reason to choose one order over another.
Well today I realized that it makes more sense to place the API headers for the library being compiled ahead
of the system headers to help QC the API. My reasoning is that a lot of people probably include the system headers first so it might be easy for a missing system #include
in an API header to slip by. For example, I have several API headers that require ssize_t
, but if the API header is normally included after several POSIX headers it might go unnoticed if I forget to #include <unistd.h>
Does anyone else see a benefit in changing the order of #include
s, or am I just taking "orderly code" too far?