C programming
C project architecture guidelines #
Functions exposed in the header are like public methods #
Think of each module like a class. The functions you expose in the header are like public methods. Only put a function in the header if it part of the module’s needed interface.
Avoiding circular module dependencies #
Avoid circular module dependencies. Module A and module B should not call each other. You can refactor something into a module C to avoid that.
Operatins within the same module should have a create and delete function interface
#
Again, following the C++ pattern, if you have a module that can perform the same operations on different instances of data, have a create and delete function in your interface that will return a pointer to struct that is passed back to other functions. But for the sake of encapsulation, return a void pointer in the public interface and cast to your struct inside of the module.
Avoid module scope variables #
Avoid module-scope variables – the previously described pattern will usually do what you need. But if you really need module-scope variables, group them under a struct stored in a single module-scope variable called “m” or something consistent. Then in your code whenever you see “m.variable” you will know at a glance it is one of the module-scope structs.
Define HEADER name to avoid double including and/or header problems #
To avoid header trouble, put #ifndef MY_HEADER_H #define MY_HEADER_H
declaration that protects against double including. The header .h file for your
module, should only contain #includes needed FOR THAT HEADER FILE. The module
.c file can have more includes needed for the compiling the module, but don’t
add those includes into the module header file. This will save you from a lot of
namespace conflicts and order-of-include problems.