EPITA Programming style standard
EPITA C99 Coding Style Standard
This document is intended to uniformize the coding styles of EPITA
engineering students during their second term.
Covered topics:
- Naming conventions
- Local layout (block level)
- Global layout (source file level), including header files and file headers
- Project layout, including
Makefile's
The specifications in this document are to be known in detail by
all students.
During the second period, all submitted projects must comply
exactly with the standard; any infringement causes the mark to
be multiplied by 0.
--- The Detailed Node Listing ---
How to read this document
Naming conventions
Preprocessor-level specifications
Writing style
Global specifications
Project layout
Differences with previous versions
Index and Table of Contents
1 How to read this document
This document adopts some conventions described in the following nodes.
1.1 Vocabulary
This standard uses the words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL as described in RFC
2119.
Here are some reminders from RFC 2119:
- MUST
- This word, or the terms REQUIRED or SHALL, mean that the
definition is an absolute requirement of the specification.
- MUST NOT
- This phrase, or the terms PROHIBITED or SHALL NOT, mean that
the definition is an
absolute prohibition of the specification.
- SHOULD
- This word, or the adjective RECOMMENDED, mean that there may exist
valid reasons in particular circumstances to ignore a particular item,
but the full implications must be understod and carefully weighted
before choosing a different course.
- SHOULD NOT
- This phrase, or the phrase NOT RECOMMENDED, mean that there may exist
valid reasons in particular circumstances when the particular behavior
is acceptable or even useful, but the full implications should be
understood and the case carefully weighed before implementing any
behavior described with this label.
- MAY
- This word or the adjective OPTIONAL, mean that an item is truly
optional. One may choose to include the item because a particular
circumstance requires it or because it causes an interesting
enhancement.
An implementation which does not comply to an OPTIONAL item MUST be
prepared to be transformed to comply at any time.
1.2 Rationale - intention and extension
Do not confuse the intention and extension of this document.
The intention is to limit obfuscation abilities of certain students
with prior C experience, and uniformize the coding style of all
students, so that group work does not suffer from style
incompatibilities.
The extension, that is, the precision of each “rule”, is there to
explain how the automated standard verification tools operate.
In brief, use your common sense and understand the intention, before
complaining about the excessive limitations of the extension.
1.3 Beware of examples
Examples of this standard are there for illustratory purposes only. When
an example contradicts a specification, the specification is authoritative.
Be warned.
As a side-note, do not be tempted to “infer” specifications from the
examples presented, or they might “magically” appear in new revisions.
2 Naming conventions
Names in programs must comply to several rules. They are described
in the following nodes :
2.1 General naming conventions
2.2 Name capitalization
- Variable names, C function names and file names MUST be expressed
using lower case letters, digits and underscores only. More
precisely, entity names MUST be matched by the following regular
expression:
[a-z][a-z0-9_]*
Rationale: for this regular expression: while this is a technical
requirement for C code, it is not for filenames. Filenames with uncommon
characters or digit prefixes are inelegant.
- C macro names MUST be entirely capitalized.
- C macro arguments MUST be capitalized:
#define XFREE(Var) \
do \
{ \
if (Var) \
free(Var); \
} \
while (0)
2.3 Name prefixes
- When declaring types, type names MUST be prefixed according to
the group they belong to: structure names MUST start with
s_, basic type aliasing with t_, union names with
u_, enumeration names with e_ and function pointers
with f_. Beware, the prefix is not part of the
identifier, thus “anonymous typedefs” of the form
typedef int t_; are PROHIBITED.
typedef unsigned char t_cmap[COLOR_WIDTH * NCOLORS];
typedef unsigned char t_pixel;
typedef char* t_string;
struct picture
{
int width;
int height;
t_cmap cmap;
t_pixel *picture;
};
typedef int (*f_open)(char*, int, int);
Rationale: for not
using suffixes instead: identifiers ending with _t
are reserved by POSIX (beside others).
Rationale: for using prefixes: they are
the first characters read while the eye is parsing, and allow to tag the
identifier without need to read it entirely.
- Structure and union names SHOULD be aliased using typedef. It
is therefore mandatory to define shortcut names to structures, unions and
enumerations using the significant prefix: s_ for structures,
u_ for unions and e_ for enumerations.
typedef struct text
{
t_string title;
t_string content;
} s_text;
typedef union
{
char c;
short s;
int i;
long long l;
} u_cast;
- When defining a typedef on an a type that is already a typedef,
the prefix of the type must be preserved if the original type is prefixed
by e_, f_, s_, t_ or u_.
typedef struct foo s_foo;
typedef s_foo *s_foo_ptr;
In this example, the s_ prefix was preserved even though
s_foo_ptr is a pointer-type.
- Global variable identifiers (variable names in the global scope),
when allowed/used, MUST start with g_.
3 Preprocessor-level specifications
The global layout of files, and sections of code pertaining to the C
preprocessor, including file inclusion and inclusion protection, must
comply to specifications detailed in the following sections.
3.1 File layout
3.2 Preprocessor directives layout
3.3 Macros and code sanity
- C macro names MUST be entirely capitalized (see Name capitalization).
- As a general rule, preprocessor macro calls SHOULD NOT break code
structure. Further specification of this point is given below.
- Macro call SHOULD NOT appear
where function calls wouldn't otherwise be appropriate. Technically
speaking, macro calls SHOULD
parse as function calls.
This is bad style:
|
#define MY_CASE(Name) \
case d_ ## Name: \
return go_to_ ## Name();
[...]
switch (direction)
{
MY_CASE(left)
MY_CASE(right)
default:
break;
}
|
| This is more elegant:
|
#define MY_CASE(Action) \
return go_to_ ## Action();
[...]
switch (direction)
{
case d_left:
MY_CASE(left);
break;
case d_right:
MY_CASE(right);
break;
default:
break;
}
|
|
Rationale: macros should not allow for hidden syntactic
“effects”. The automated standard conformance tool operates over
unprocessed input, and has no built-in preprocessor to “understand”
macro effects.
- The code inside a macro definition MUST follow the specifications
of the standard as a whole.
3.4 Comment layout
For additional specifications about comments, see
File layout and Global specifications.
3.5 Header files and header inclusion
4 Writing style
The following sections specify various aspects of what constitutes
good programming behaviour at the language level. They cover
various aspects of C constructs.
4.1 Blocks
4.2 Structures variables and declarations
4.2.1 Alignment
- Declared identifiers MUST be aligned with the function name, using
tabulations only, even for identifiers declared within a block.
Hint: Emacs users, use M-I.
The following is wrong:
|
int foo()
{
int i = 0;
// some code
int j = 42;
return (i);
}
|
| The following is correct:
|
int foo()
{
int i = 0;
// some code
int j = 42;
return (i);
}
|
|
- In C, pointerness is not part of the type. Therefore, the pointer symbol
(*) in declarations MUST appear next to the variable name, not
next to the type.
The following is incorrect (and probably does not have the intended meaning):
| The following is correct:
|
const char *str1;
const char *str2;
|
|
- Structure and union fields MUST be aligned with the type name,
using tabulations.
- When declaring a structure or an union, there MUST be only
one field declaration per line.
This is incorrect:
|
struct s_point
{
int x, y;
long color;
};
|
| This is correct:
|
struct s_point
{
int x;
int y;
long color;
};
|
|
- Enumeration values MUST be capitalized.
- Enumeration values MUST appear on their own lines.
This is incorrect:
|
enum e_boolean
{ true, false };
|
| This is correct:
|
enum e_boolean
{
BOOL_TRUE,
BOOL_FALSE
};
|
|
4.2.2 Declarations
4.3 Statements
- A single line MUST NOT contain more than one statement.
This is wrong:
|
x = 3; y = 4;
x = 3, y = 4;
|
| This is correct:
|
- Commas MUST NOT be used on a line to separate statements.
- The comma MUST be followed by a single space, except when they
separate arguments in function (or macro) calls and declarations and the
argument list spans multiple lines: in such cases, there MUST NOT be
any trailing whitespace at the end of each line.
- The semicolon MUST be followed by a newline, and MUST NOT be
preceded by a whitespace, except if alone on the line.
- For a detailed review of exceptions to the three previous rules,
See Control structures.
- Keywords MUST be followed by a single whitespace, except
those without arguments. This especially implies that return
without argument, like continue and break, MUST NOT be
separated from the following semicolon by a whitespace.
- When the return statement takes an argument, this argument
MUST be enclosed in parenthesis.
This is wrong:
| This is correct:
|
- The goto statement MUST NOT be used.
4.4 Expressions
- All binary and ternary operators MUST be padded on the left and right by one
space, including assignment operators.
- Prefix and suffix operators MUST NOT be padded, neither on the left nor
on the right.
- When necessary, padding is done with a single whitespace.
- The . and -> operators MUST NOT be padded, neither.
This is wrong:
| This is correct:
|
x += 10 * ++x;
y = a ? b : c;
|
|
- There MUST NOT be any whitespace between the function and the opening
parenthesis for arguments in function calls.
- ”Functional” keywords MUST be followed by a whitespace, and their
argument(s) MUST be enclosed between parenthesis.
Especially note that sizeof is a keyword, while
exit is not.
This is wrong:
|
p1 = malloc (3 * sizeof(int));
p2 = malloc(2 * sizeof char);
|
| This is correct:
|
p = malloc(3 * sizeof (int));
|
|
- Expressions MAY span over multiple lines. When a line break occurs
within an expression, it MUST appear just after a binary operator,
in which case the binary operator MUST NOT be padded on the right by a
whitespace.
4.5 Control structures
4.5.1 General rules
- Control structure keywords MUST be followed by a whitespace.
This is wrong:
|
This is correct:
|
- The conditional parts of algorithmic constructs (if, while,
do, for), and the
else keyword,
MUST be alone on their line.
These constructs are incorrect:
|
while (*s) write(1, s++, 1);
if (x == 3) {
foo3();
bar();
} else {
foo();
baz();
}
do {
++x;
} while (x < 10);
|
| These are correct:
|
while (*s)
write(1, s++, 1);
if (x == 3)
{
foo3();
bar();
}
else
{
foo();
baz();
}
do
{
++x;
}
while (x < 10);
|
|
4.5.2 while and do ... while
- The do ... while construct MAY be used, but appropriate
use of the while and for constructs is preferred.
4.5.3 for
Exceptions to other specifications (See Statements,
see Structures variables and declarations) can be found in this section.
- Multiple statements MAY appear in the initial and iteration part
of the for structure.
- For this effect, commas MAY be used to separate statements.
- Variables MAY be declared in the initial part of the
for construct.
This is wrong:
|
int i;
for (i = 0, j = 1;
p = i + j, p < 10;
++i, ++j)
{
/* ... */
}
|
| These are correct:
|
int i;
for (i = 0, j = 1, p = i + j;
p < 10;
++i, ++j, p = i + j)
{
/* ... */
}
for (int j = 0; j < 10; ++j)
{
// ...
}
|
|
- As shown in the previous examples, the three parts of the for
construct MAY span over multiple lines.
- Each of the three parts of the for construct MAY be
empty. Note that more often than not, the while construct
better represents the loop resulting from a for with an
empty initial part.
These are wrong:
| This is correct:
|
4.5.4 Loops, general rules
- To emphasize the previous rules, single-line loops
(for and while) MUST have their terminating
semicolon on the following line.
This is wrong:
|
for (len = 0; *str; ++len, ++str);
|
|
These are correct:
|
for (len = 0; *str; ++len, ++str)
;
|
|
Rationale: the semicolon at the end of the first line is a common source
of hard-to-find bugs, such as:
while (*str);
++str;
Notice how the discreet semicolon introduces a bug.
4.5.5 The switch construct
4.6 Trailing whitespace
5 Global specifications
Some general considerations about the C sources of a project
are specified in the following sections.
5.1 Casts
- As a general rule, C casts MUST NOT be used. The only exception to this
requirement is described below.
Rationale: good programming behavior includes proper type handling.
- For the purpose of so-called genericity, explicit conversion between
compatible pointer types using casts MAY be used, but
only with the explicit allowance from the
assistants. “Compatible” pointer types are types accessible from one
another in the subtyping or inheritance graph of the project.
Hint: if you do not know what are subtyping nor inheritance, avoid using
casts.
5.2 Functions and prototyping
- Any exported function MUST be properly prototyped.
- Prototypes for exported function MUST appear in header files and
MUST NOT appear in source files.
- The source file which defines an exported function MUST include the
header file containing its prototype.
This layout is correct:
File my_string.h:
|
#ifndef MY_STRING_H_
# define MY_STRING_H_
# include <stddef.h>
size_t my_strlen(const char *);
char *my_strdup(const char *);
#endif /* !MY_STRING_H_ */
|
|
|
File my_strlen.c:
|
#include "my_string.h"
size_t my_strlen(const char *s)
{
/* definition of my_strlen */
}
|
| File my_strdup.c:
|
#include "my_string.h"
char *my_strdup(const char *s)
{
/* definition of my_strdup */
}
|
|
- Prototypes MUST conform to the C99 standard: they must specify
both the return type and the argument types.
- Prototypes SHOULD include argument names (in addition to their type).
These are invalid prototypes:
|
foo();
bar(int, long);
int baz();
|
| These are valid prototypes:
|
int foo(int x);
void bar(int x, long y);
int baz(void);
|
|
- Within a block of prototypes, function names SHOULD be aligned.
This is inelegant:
|
unsigned int strlen(const char *);
char *strdup(const char *);
|
|
This is elegant:
|
unsigned int strlen(const char *);
char *strdup(const char *);
|
|
- Function names in prototypes SHOULD be aligned with other
declarations.
This is not recommended:
|
int g_counter;
struct s_block *allocate(unsigned int size);
void release(struct s_block *);
|
|
This is recommended:
|
int g_counter;
struct s_block *allocate(unsigned int size);
void release(struct s_block *);
|
|
- Function argument lists SHOULD be split between each argument, after
the comma. In addition, the arguments MUST be properly aligned.
|
char bar(char c,
short s,
int i);
void foo(s_text* text,
int size)
{
bar('k', 21, 42);
}
|
- Functions MUST NOT take more than 4 arguments.
- Functions MUST NOT return structures or unions by value. Structures or
unions MUST be passed by address as function arguments.
- Function arguments passed by address SHOULD be declared
const unless actually modified by the function.
- Function arguments passed by address SHOULD be declared
restrict when they point to data that can be accessed only through
that pointer.
5.3 Global scope and storage
- There MUST be at most five exported functions
per source file.
- There MUST be at most one non-function exported symbol per
source file.
Rationale: when statically linking binaries against
libraries, most linker algorithms operate with object file granularity,
not symbol granularity. With only one exported symbol per source file,
the link process has the finest granularity. Hint: track exported
symbols with nm.
- There SHOULD NOT be any unused local (tagged with static)
functions in source files. Hint: hunt unused functions with
gcc -Wunused.
- In order to block known abuses of the previous rules, there MUST NOT
appear more than ten functions (exported + local) per source file.
- Global variables are NOT RECOMMENDED. When required by a particular
circumstance, there MUST be only one global variable per
file.
- Static variables MUST be constant, other kind of static variable
are NOT RECOMMENDED.
- When initializing a static array or structure with const elements, the
initializer value MUST start on the line after the declaration:
This is wrong:
|
static int primes[] = { 2, 3, 5, 7, 11 };
|
|
These are correct:
|
static const int primes[] =
{
2, 3, 5, 7, 11
};
static const struct
{
char c;
void (*handler)(void *);
} handlers[] =
{
{ 'h', &left_handler },
{ 'j', &up_handler },
{ 'k', &down_handler },
{ 'l', &right_handler },
{ '\0', 0 }
};
|
|
5.4 Code density and documentation
6 Project layout
Specifications in this chapter are to be altered (most often
relaxed) by the assistants on a per-project basis. When in
doubt, follow the standard.
6.1 Directory structure
Each project sources MUST be delivered in a directory, the name of
which shall be announced in advance by the assistants.
In addition to the usual source files, and without additional
specification, it SHOULD contain a number of
additional files:
- AUTHORS
- This file MUST contain the authors' names, one per line. Each line
MUST contain an asterisk, then a login name. The first name to appear
is considered as the head of the project.
Rationale: this file is to be grep'ed over with a
^\* \([a-z-][a-z-]*_[a-zA-Z0-9_-]\).*$
regexp pattern to extract login names.
It is especially important to note that this specifications allows
for documenting a project by using actual text in the AUTHORS
file: the regexp will only extract the relevant information. For example,
consider the following text:
|
This project was written with the help of:
* foo_b (Foo Bar), main developer;
* baz_y (Baz Yay), code consultant;
* chiche_f (Chichery Florent), coffee maker;
Many thanks to them for their contribution to the project.
|
Because the regex only matches the relevant information, it constitutes
a valid AUTHORS file.
- configure
- When the project contract allows so, and only then, the script
configure is automatically run before running the
make
command. It MAY create or modify files in the current directory or
subdirectories, but MUST NOT expect to be run from a particular
location.
Rationale: allow for site configuration with Autoconf or similar tools.
- Makefile*
- Unless explicitly forbidden, the project directory MAY contain an
arbitrary number of files with names derived from “Makefile”. These
files are optional, although a Makefile MUST be present at the
time the command
make is run.
Rationale: the Makefile may include Makefile-rules.make
or similar files for architecture-dependent compilation options.
6.2 Makefiles and compilation rules
- The input file for the
make command MUST be named Makefile,
with a capital “M”.
Rationale: although the latter name makefile is also valid, common
usage prefer the former.
- The Makefile (provided or generated by
configure) SHOULD
contain the all, clean and distclean rules.
- The Makefile MUST NOT use non-standard syntax. In particular,
it MUST NOT expect to be parsed by GNU make (“
gmake”).
- The default rule MUST be the
all rule.
- The
clean rule SHOULD clear object files, temporaries and
automatic editor backups from the source tree.
- The
distclean rule MUST depend on the clean rule, and
SHOULD remove binaries, shared objects and library archives from
the source tree.
- C sources MUST compile without warnings when using strict
compilers. The GNU C compiler, when provided with strict warning
options, is considered a strict compiler for this purpose.
Especially, when GCC is available as a standard compiler on a system,
source code MUST compile with GCC and the following options:
-Wall -W -std=c99 -pedantic -Werror
Additionally, it SHOULD compile without warnings with GCC and the
following options (all documented in the GCC manual page):
-Wall -W -std=c99 -pedantic
-Wfloat-equal -Wundef -Wshadow -Wpointer-arith
-Wbad-function-cast -Wcast-qual -Wcast-align
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs
-Wunreachable-code
- The previous requirement does not imply that the Makefile
must actually use these flags. It does not imply that GCC must be
always used: only the command cc is guaranteed to be available, and may
point to a different compiler.
- C compilation rules SHOULD use the warning flag specifiers when
possible.
- Makefile rules MUST NOT expect the presence of GCC on all
target architectures.
- As a side effect of the two previous rules, compiler differences and
architecture-dependent flags MUST be handled by appropriate use of
the
uname command. In particular, the environment variable
HOSTTYPE MUST NOT be used for this purpose, since it has a
shell-dependent and architecture-dependent behaviour.
7 Differences with previous versions
7.1 Differences with the legacy version
The 2002 document was intended to supercede the legacy norme, first written
in (??), and last updated in October, 2000.
It was based on the previous version, adding finer distinctions between
requirements and recommendations, updating previous specifications and adding
new ones.
Here is a summary of the major changes:
- Specification of the differences between requirements and
recommendations was added.
- Indentation requirements were clarified.
- Header file specifications were clarified and updated to match modern
conventions.
- The switch construct is now allowed under special circumstances.
- Prototyping specifications were clarified and detailed.
- Naming conventions were clarified.
- Declaration conventions were clarified and relaxed for some useful
cases.
- Line counting of function bodies was relaxed. The limit on the number of
function arguments was explained and relaxed.
- Comment specifications, including standard file headers, were clarified
and detailed.
- Project layout specifications were added. Default Makefile rules and
rule behaviors were updated to match modern conventions.
- Special specifications for C++ were added.
In addition to these changes, the structure of the standard itself has been
rearranged, and an index was added.
7.2 Differences with year 2002
Starting with 2003, the assistants decided to revert to a short
specification written in french, for readability convenience.
The english document you are now reading was a complement that could
optionnally used as a substitute.
Here is a summary of the major changes:
- Names are required to match a regular expression.
- Preprocessor directives indentation between #if and #endif
is now mandatory.
- Header protection tags now have a _ appended.
- Multiple declarations per line are now forbidden, due to abuses during
the past year.
- Cumulated declaration and initialization is now explicitely authorized.
- Local external declarations (extern in block scope) are now
implicitely authorized.
- Statement keywords without argument are not followed by a white space
anymore.
- else if cannot appear on a single line any more.
- Single-line empty loops are now forbidden (the traling semicolon must
appear on the following line).
- Return-by-value of structures and unions is now implicitely authorized.
- typedef of structures and unions is now disallowed.
- Line count for function bodies is now absolute again (empty lines,
assert calls and switch cases are counted).
- Project recommendations now insist on the fact that GCC must not always
be used and that the configure script is not always allowed.
- Sample Makefile and configure scripts are not provided
anymore.
7.3 Differences with year 2003
Starting from the year 2004, this english version is the official
specification document used.
The major changes are:
- Expressions tolerated at initialisation are clearly specified.
- English comments are now mandatory.
- Comments for functions are on declarations and not definitions.
- There can be only static const variable, no more static variables
are tolerated.
- Auto-generated headers can now have more than 80 columns.
- Structure and unions must be returned and passed by address.
7.4 Differences with year 2004
No significant changes: minor corrections to some examples.
7.5 Differences with year 2005
The following changes were introduced during the year 2006.
Here is a summary of the major changes. These modifications were
introduced to make the whole coding style standard more coherent.
- Functions' body can contain comments and blank lines to make the code
more understandable and clearer. These additional lines are not counted in the
function's body 25 lines limit.
int foo(char *s)
{
int length;
/* sanity check */
if (s == NULL)
return (-1);
/* do the job */
length = strlen(s);
return (length);
}
- Function argument lists must be split between each argument, after the
comma and the arguments must be properly aligned.
int open(const char *pathname,
int flags);
void bar(char *s,
int flags)
{
int fd;
if ((fd = open(s, flags)) == -1)
return;
/* ... */
}
- When the return statement contains an argument, this argument
must be enclosed in parenthesis.
- Structures, unions and enumerations should be aliased using typedefs and
using specific prefixes: s_ for structures, u_ for unions, e_ for
enumerations and f_ for function pointers.
union cast
{
char c;
short s;
int i;
long l;
};
typedef union cast u_cast;
int main(int argc,
char **argv)
{
union cast cast1;
u_cast cast2;
/* ... */
}
- Global variable names must be prefixed by g_.
- Enumerations values must be capitalized.
- Enumeration value alignment with the enumeration name is no
longer mandatory.
7.6 Differences with year 2006
The following changes were introduced during the year 2007.
Here is a summary of the major changes.
Other minor changes this year include:
- The rule introduced last year which required that function arguments to be
spanned over multiple lines (one argument per line) was cancelled.
- The EPITA-style header is no longer mandatory because it generates spurious
conflicts with Source Control Management softwares and provides little value
added.
7.7 Differences with the ANSI C Coding Style
7.7.1 Comments
see Comment layout
- This was changed :
- Into :
- Two new examples have been added
7.7.2 Variable declarations
see Structures variables and declarations
- This has been changed :
- Declared identifiers MUST be aligned with the function name, using
tabulations only.
- Into :
- Declared identifiers MUST be aligned with the function name, using
tabulations only, even for identifiers declared within a block.
- The example has been changed.
- This has been added :
- When initializing a local structure (a C99 feature), the
initializer value MUST start on the line after the declaration:
- An example has been added.
7.7.3 For construct
see Control structures
- This has been changed :
- Variables MUST NOT be declared in the initial part of the
for construct.
- Into :
- Variables MAY be declared in the initial part of the
for construct.
- An example has been added.
7.7.4 Prototypes
see Functions and prototyping
- This has been changed :
- Prototypes MUST conform to the ANSI C standard: they must specify
both the return type and the argument types.
- Into :
- Prototypes MUST conform to the C99 standard: they must specify
both the return type and the argument types.
- This has been added :
- Function arguments passed by address SHOULD be declared
restrict when they point to data that can be accessed only through
that pointer.
7.7.5 Compilation flags
see Project layout
Index and Table of Contents
- #define: Macros and code sanity
- #define: Preprocessor directives layout
- #if 0: File layout
- #ifdef: Preprocessor directives layout
- #ifdef: Header files and header inclusion
- .h files: Header files and header inclusion
- abbreviations: General naming conventions
- alignment of function names in a declaration block: Functions and prototyping
- alignment, enumeration values: Structures variables and declarations
- alignment, functions and declarations: Structures variables and declarations
- alignment, pointer declarations: Structures variables and declarations
- alignments, structure and union fields: Structures variables and declarations
all: Makefiles and compilation rules- ANSI C, for prototypes: Functions and prototyping
- arguments, do not pass structures by value: Functions and prototyping
- arguments, maximum number in functions: Functions and prototyping
- AUTHORS: Directory structure
- blank lines, forbidden in functions: Code density and documentation
- blank lines, within blocks: Blocks
- blocks: Blocks
- braces: Blocks
- break: Statements
- break: Control structures
- capitalization: Macros and code sanity
- capitalization: Name capitalization
- case: Control structures
- casts, do not use: Casts
clean: Makefiles and compilation rules- commas: Statements
- commas, within for: Control structures
- comments, after #else and #endif: Preprocessor directives layout
- comments, before functions only: Code density and documentation
- comments, delimiters: Comment layout
- comments, file header: File layout
- comments, language: Comment layout
- comments, layout: Comment layout
- compilation flags: Makefiles and compilation rules
- compilation rules: Makefiles and compilation rules
configure: Directory structure- const, function arguments: Functions and prototyping
- continue: Statements
- control structure keywords: Control structures
- CR+LF: File layout
- CR+LF: Trailing whitespace
- declarations with initialization: Structures variables and declarations
- declarations, one per line: Structures variables and declarations
- declarations, within blocks: Blocks
- default: Control structures
- delimiters, comments: Comment layout
- directives, layout: Preprocessor directives layout
- directives, line breaks: Preprocessor directives layout
- directives, macros: Macros and code sanity
- disabling code blocks: File layout
distclean: Makefiles and compilation rules- do: Control structures
- do ... while: Control structures
- e_: Name prefixes
- else: Control structures
- empty loop body: Control structures
- empty statements, within for: Control structures
- enum: Structures variables and declarations
- enumerations, use within switch: Control structures
- examples, warning: Beware of examples
- exit: Expressions
- exported functions: Global scope and storage
- expressions, padding with spaces: Expressions
- f_: Name prefixes
- for: Control structures
- for, empty body: Control structures
- functions and globals, maximum number: Global scope and storage
- functions, maximum number of arguments: Functions and prototyping
- functions, no comments within body: Code density and documentation
- functions, prototype over multiple lines: Functions and prototyping
- functions, return type: Functions and prototyping
- g_: Name prefixes
- GCC, use for warnings: Makefiles and compilation rules
- genericity: Casts
- global functions: Global scope and storage
- global variables: Global scope and storage
- globals, maximum number: Global scope and storage
- gmake: Makefiles and compilation rules
- goto: Statements
- header files: Header files and header inclusion
- headers, inclusion: Header files and header inclusion
- headers, prototypes of exported functions: Functions and prototyping
- heading comments: File layout
- if: Control structures
- initialization: Structures variables and declarations
- inner declarations: Structures variables and declarations
- keywords, followed by whitespace: Statements
- keywords, followed by whitespace: Expressions
- keywords, followed by whitespace: Control structures
- layout, comments: Comment layout
- layout, directives: Preprocessor directives layout
- layout, files: File layout
- line breaks in preprocessor directives: Preprocessor directives layout
- line breaks, within arguments list: Functions and prototyping
- line breaks, within for: Control structures
- line count within function bodies: Code density and documentation
- lines, maximum length: File layout
- link granularity: Global scope and storage
- macro calls: Macros and code sanity
- macro names: Name capitalization
make: Directory structure- Makefile: Makefiles and compilation rules
- Makefile: Directory structure
- makefile, do not use: Makefiles and compilation rules
- MAY: Vocabulary
- multiple declarations: Structures variables and declarations
- multiple inclusion protection: Header files and header inclusion
- MUST: Vocabulary
- MUST NOT: Vocabulary
- names: Naming conventions
- names, abbreviations: General naming conventions
- names, alignment of functions: Functions and prototyping
- names, case of: Name capitalization
- names, enumeration values: Structures variables and declarations
- names, for arguments in prototypes: Functions and prototyping
- names, global variables: Name prefixes
- names, header protection key: Header files and header inclusion
- names, macros: Name capitalization
- names, prefixes: Name prefixes
- naming conventions: Naming conventions
- operators, padding: Expressions
- OPTIONAL: Vocabulary
- options, warning generation: Makefiles and compilation rules
- pointerness, alignment of declarations: Structures variables and declarations
- preprocessor macros: Macros and code sanity
- preprocessor, directives: Preprocessor directives layout
- prototypes, for exported functions: Functions and prototyping
- prototypes, spanning over multiple lines: Functions and prototyping
- Rationale: Directory structure
- Rationale: Comments changes
- Rationale: Makefiles and compilation rules
- Rationale: Comments changes
- Rationale: Name capitalization
- Rationale: Code density and documentation
- Rationale: Comment layout
- Rationale: Control structures
- Rationale: Global scope and storage
- Rationale: Macros and code sanity
- Rationale: Name prefixes
- Rationale: Control structures
- Rationale: Directory structure
- Rationale: Trailing whitespace
- Rationale: Casts
- Rationale: File layout
- rationale, definition: Rationale - intention and extension
- RECOMMENDED: Vocabulary
- REQUIRED: Vocabulary
- requirement: Vocabulary
- restrict, function arguments: Functions and prototyping
- return: Statements
- return, replaces break within switch: Control structures
- RFC 2119: Vocabulary
- s_: Name prefixes
- semicolons: Statements
- SHALL: Vocabulary
- SHOULD: Vocabulary
- sizeof: Expressions
- spaces, within expressions: Expressions
- spelling mistakes: Comment layout
- spelling mistakes: General naming conventions
- statement, multiple per line: Statements
- statement, within for: Control structures
- static: Global scope and storage
- structures, do not use as function return values: Functions and prototyping
- structures, field alignment: Structures variables and declarations
- switch: Control structures
- t_: Name prefixes
- tabulations: Trailing whitespace
- template comment for headers: File layout
- trailing whitespace: Trailing whitespace
- transtyping, do not use: Casts
- u_: Name prefixes
- unions, field alignment: Structures variables and declarations
- unused functions cannot appear: Global scope and storage
- variables, declaration within for: Control structures
- variables, multiple per line: Structures variables and declarations
- variables, number of global variable declarations per file: Global scope and storage
- warnings: Makefiles and compilation rules
- while: Control structures
- while, empty body: Control structures
- whitespace, at the end of a line: Trailing whitespace