8 Differences with the C Coding Style

This is a non exhaustive list of the differences between the guidelines provided by this document and that provided by the C Coding Style.

• You don't have to and even MUST NOT add s_, u_, e_, t_ before your type names.
• Global variables don't have to be prefixed by g_.
• You don't have to and even SHOULD NOT add the EPITA header to all your files. It is deprecated and useless. SVN does a better and more useful job if you want to track modifications.
• You can write your comments the way you want instead of having to stick to

            /*
            ** Comment.
            */
       

• You don't have to and even SHOULD NOT align everything (declarations, arguments, local variable names, member fields in structures, enums or unions, etc).
• Pointerness is to be expressed as part of the type (int* p) despite the (sad) fact that int* p, q declares a pointer and an integer. You MUST NOT declare two things on the same line anyway.
• When declaring and initializing your variable you can initialize them the way you want, not only with simple expressions as required by the C Coding Style.
• The return value doesn't have to be in parentheses. Actually, it SHOULD NOT unless adding parentheses makes it easier to read (e.g, because it spans over more than one line).
• Almost all parentheses must be preceded by a whitespace.
• When breaking a long expression so that it spans over more than one line, the break must occur before a binary operator, not after. This is what the gnu Coding Standards suggest (and justifies).
• You are allowed and advised to write else if on the same line.
• Functions can take more than 4 arguments although it is usually not necessary.
• You are not limited to any number of functions per file. A common practice in C++ is to define all the methods of a class in the same file.
• Function bodies MAY contain up to 50 (useful) lines maximum instead of 25.