Following are the list of coding styles and best practices which are followed in various organizations. However these standards varies from company to company but I tried to compile few commonly practiced standards which are useful for good readability and long term maintainability of the code.
Outside of comments and documentation, never use spaces. Indentation is done using tabs only;
Do not use tabs to align text documentation. Although the preferred tab width is 8 characters, changing tab width should not interfere with the layout/alignment of code, only indentation;
Maximum text width is 80 columns, with very few exceptions;
Do not put multiple statements on a single line:
wrong:
if (condition) do_this;
right:
if (condition)
do_this;
Variables should always be in lower case, like:
char *tmp_buf;
int length;
int i, j;
Macros (#defines) for constants should be in upper case, like:
#define MAX_NUM_ENTRIES 10
#define WHATEVER 0x220
Do not use typedefs to hide structs or enums, unless it's absolutely necessary to create an abstract type. If that's the case add a '_t' suffix to identify it;
Never use typedefs just to hide pointers, unless it's a function pointer;
CamelCase is discouraged, with one exception:
In cases where it better integrates with other coding-style, to avoid mixing different cases (for example, if the code is *heavily* tied to some library which uses such notation);
When using a (semi) object-oriented paradigm, separate "classes" from methods/attributes using '__', as below:
foobar__do_something() ["class":foobar, method:do_something()]
user_adm__change_pass() ["class":user_adm, method:change_pass()]
bobex__lock ["class":bobex, attribute:lock]
backend_sysfs__methods [...]
This must be done carefully, since it may cause unwanted code pollution;
All non-static functions should have a prefix to avoid symbol names clashing, as well as new defined types and exported macros, as in the example below:
atc_dos2unix()
^^^
When performing error checking, use goto to help creating a single return point. Do not abuse goto usage though (avoid going up, going too far, too much labels, etc);
The most important lesson about coding style is to keep your source consistent. For example, using non-idiomatic (alien) constructions is strongly discouraged;
About header files and modularization:
Source code has to be split into modules (AKA units), which are defined as a collection of implementation files (.c) with an interface exported through a header file (.h);
The inclusion (#include) of headers must reflect the dependencies between modules in the implementation. The most important implications of this statement are:
. implementation files (.c) *must* include *all* headers it directly depends on;
. implementation files (.c) *must not* include headers it doesn't directly depend on;
. headers should only include headers (nested headers) when there's a need for a definition or declaration;
. headers should never include other headers just to create a "single point of inclusion".
Local headers (from the same component) are included using "", with an exception for the auto-generated files "config.h" and "system.h", which can be included using <>.
