top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

C Coding Style and Best Practices

+10 votes
419 views

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 <>.

posted Jan 15, 2014 by anonymous

  Promote This Article
Facebook Share Button Twitter Share Button LinkedIn Share Button

...