C Coding Style
Proposal for Icecast
Indent with (4) spaces, no tabs.
A Line Should Not Exceed 80 Characters.
do statements should either have braces or be on a single line.
Do not put braces next to keywords. Put a space between.
For complex conditions you can put spaces in the start and the end of the statement,
if it helps readability:
One line form:
(Should be used only where it really makes sense and stays readable)
If Then Else Formatting
Falling through a case statement into the next case statement shall be permitted as long as a comment is included.
Functions should limit themselves to a single page of code.
Unlike conditions, functions should have the curly brace on a newline.
No whitespace between function name and brace.
If variable list is too long, break it as follow
Macros and inline functions
Don’t change syntax via macro substitution.
Macros for small tasks are ok, longer ones should be, when possible, inline functions
When putting expressions in macros always wrap the expression in parenthesis
Placement and formating
Variable declarations should always go to the begin of the current scope.
Each block of declarations is terminated by a single blank line.
Variables are never declared mixed with code.
Types should be chosen by there definition. Generic or native types should be avoided
as they are often defined in a way that can result in portability problems.
Common errors include assumptions about the size or data structure of types.
Examples include the use of
short when a 16 bit integer type is required.
The correct type here is
Good types include:
|signed integer type of fixed size (N bits)
|unsigned integer type of fixed size (N bits)
|Unsigned type used for counting objects in memory. Such as results of sizeof(), array sizes and indices, string lengths, or as counter loops iterating over arrays.
size_t but can in addition hold the value
-1 (often used to indicate an error).
|Blocks of memory, not 0-terminated. Often accompanied by length parameters which should have a type of
// should never be used but instead
/* comment here */.
If the comment is about what a special if case does, it should be on the next line:
Multiline comment should have text on the first line, but not on the last:
The following tags should be used in comments, when necessary, for easier finding stuff that needs to be reviewed or handled in future release.
- REVIEW: Ask for a review of this.
- REWRITE: Ask for a rewrite of this section.
- TODO: Ask for implementation of a feature.
- FIXME: Ask correcting an implementation.
- REMOVE: Remove a block or feature.
- DOCUMENT: Documentation for this block or feature is missing, incomplete or wrong and needs update.
- [BEFORE|AFTER|IN] RELEASE $version: This is relevant to release $version. $version can also be NEXT.
- [BEFORE|AFTER|IN] YEAR $yyyy: This is relevant to (4-digit) year $yyyy
- IMPORTANT: This is an important problem.
- SECURITY: This is security critical.
- LEAK: This leaks some resource (memory, file descriptors, …)