11. Naming Conventions
Individual projects will no doubt have their own naming conventions.
There are some general rules however.
-
Names with leading and trailing underscores are reserved for system
purposes and should not be used for any user-created names.
Most systems use them for names
that the user should not have to know.
If you must have your own private identifiers,
begin them with a letter or two identifying the
package to which they belong.
-
#define constants should be in all CAPS.
-
Enum constants are Capitalized or in all CAPS
-
Function, typedef, and variable names, as well as struct, union, and
enum tag names should be in lower case.
-
Many macro "functions" are in all CAPS.
Some macros (such as
getchar
and
putchar)
are in lower case
since they may also exist as functions.
Lower-case macro names are only acceptable if the macros behave
like a function call,
that is, they evaluate their parameters exactly once and
do not assign values to named parameters.
Sometimes it is impossible to write a macro that behaves like a
function even though the arguments are evaluated exactly once.
-
Avoid names that differ only in case, like foo and Foo.
Similarly, avoid foobar and foo_bar.
The potential for confusion is considerable.
-
Similarly, avoid names that look like each other.
On many terminals and printers, 'l', '1' and 'I' look quite similar.
A variable named 'l' is particularly bad because it looks so much like
the constant '1'.
In general, global names (including
enums)
should have a
common prefix identifying the module that they belong with.
Globals may alternatively be grouped in a global structure.
Typedeffed names often have
"_t"
appended to their name.
Avoid names that might conflict with various standard
library names.
Some systems will include more library code than you want.
Also, your program may be extended someday.
contents
Operators
Constants