Log in | Back to darenet.org

Development Team/Coding Standards/new

(Declarations and Types)
 
(6 intermediate revisions not shown)
Line 1: Line 1:
-
== Comments ==
+
This document gives coding conventions for the C code comprising many of DareNET's development projects.
-
Comments can add immensely to the readability of a program, but used heavily or poorly placed they can render good code completely incomprehensible. It is far better to err on the side of too few comments rather than too many - at least then people can find the code. Also, if your code needs a comment to be understood, then you should look for ways to rewrite the code to be clearer. And comments that aren't there won't get out of date. An inaccurate or misleading comment hurts more than a good comment helps, so be sure to update or remove your comments as needed.
+
Note, rules are there to be broken. Two good reasons to break a particular rule:
-
That being said, good places to put comments are:
+
# When applying the rule would make the code less readable, even for someone who is used to reading the code that follows the rules.
 +
# To be consistent with surrounding code that also breaks it (maybe for historic reasons) -- although this is also an opportunity to clean up someone else's mess.
-
* a broad overview at the beginning of a module
+
== C dialect ==
-
* data structure definitions
+
-
* global variable definition
+
-
* at the beginning of a function
+
-
* tricky steps within a function
+
-
If you do something weird, a comment to explain why can save future generations from wondering what drug you were on and where to get it. If you do something clever, brag about it. Not only will this inflate your ego, but it will also subtly tip off others as to where to look first for bugs. Finally, avoid fancy layout or decoration.
+
* While you may use C99, keep in mind that variable length arrays and macros with variable number of parameters are not well supported amongst most compilers. If you use these features, ensure you account for this (see services-darenet's HelpServ module for an example).
-
NOTE: DO NOT use C++ style single-line comments. It's consider bad practice to use them in a C program, and is not ANSI compliant.
+
* GCC is the compiler we use for almost all our testing. We recommend you use it as well. However, while use of GCC extensions are not prohibited, we don't necessarily encourage their use either.
-
You should also strive to doxify your comments, where suitable. Rambles, rants, and personal complaints do not provide any benefit to understanding code, please do not add them.
+
* Never use C++ style // single line comments.
-
'''Examples:'''
+
== Indentation ==
-
<c>/* single line comments look like this */
+
Tabs, tabs, ONLY tabs. Use one tab for each level of indentation. Spaces should ONLY be used for alignment, not indentation.
-
/*
+
Preference: Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
-
* Important single line comments look like multi-line comments.
+
-
*/
+
-
/*
+
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.
-
* Multiline comments look like this. Put the opening and closing
+
-
* comment sequences on lines by themselves. Use complete sentences
+
-
* with proper English grammar, capitalization, and punctuation.
+
-
*/
+
-
/* but you don't need to punctuate or capitalize one-liners */
+
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
-
/**
+
In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.
-
* This is a doxified comment.
+
-
*/
+
-
</c>
+
-
The opening / of all comments should be indented to the same level as the code to which it applies, for example:
+
== Braces ==
-
<c>if (fubar()) {
+
The other issue that always comes up in C styling is the placement of braces. Unlike the indent size, there are few technical reasons to choose one placement strategy over the other, but the preferred way, as shown to us by the prophets Kernighan and Ritchie, is to put the opening brace last on the line, and put the closing brace first, thusly:
-
/*
+
 
-
* Fouled up beyond all recognition. Print a nastygram
+
<c>if (x is true) {
-
* and attempt to clean up.  If that doesn't work,
+
        we do y
-
* die horribly, and try to crash the system while
+
-
* we're at it.
+
-
*/
+
-
...
+
}</c>
}</c>
-
If you put a comment on the same line as code, set it off from the code with a few tabs. Don't continue such a comment across multiple lines. For example:
+
However, there is one special case, namely functions: they have the opening brace at the beginning of the next line, thus:
-
<c>printf("hi\n"); /* hello revisited */</c>
+
<c> int function(int x)
 +
{
 +
        body of function
 +
}</c>
-
In fact, try to avoid such comments altogether - if it`s not important enough to warrant a complete sentence, does it really need to be said?
+
Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are ''right'' and (b) K&R are ''right''. Besides, functions are special anyway (you can't nest them in C).
-
== Declarations and Types ==
+
Note that the closing brace is empty on a line of its own, except in the cases where it is followed by a continuation of the same statement, i.e. a "while" in a do-statement or an "else" in an if-statement, like this:
-
Provide typedefs for all struct and union types, and put them before the type declarations. Creating the typedef eliminates clutter of extra <code>struct</code> and <code>union</code> keywords (we can see that it's a type from it's position in the declaration), and makes your structures look like first-class types in the language. Putting the typedefs before the type declarations allows them to be used when declaring circular types. It is also nice to have a list of all new reserved words up front.
+
<c>do {
 +
        body of do-loop
 +
} while (condition);</c>
-
'''Examples:'''
+
and
-
<c>typedef struct Foo Foo;
+
<c>if (x == y) {
-
typedef struct Bar Bar;
+
        ..
 +
} else if (x > y) {
 +
        ...
 +
} else {
 +
        ....
 +
}</c>
-
struct Foo {
+
Rationale: K&R.
-
    Bar *bar;
+
-
};
+
-
struct Bar {
+
Also, note that this brace-placement also minimizes the number of empty (or almost empty) lines, without any loss of readability. Thus, as the supply of new-lines on your screen is not a renewable resource (think 25-line terminal screens here), you have more empty lines to put comments on.
-
    Foo *foo;
+
-
};</c>
+
-
This gives a particularly nice scheme of exporting opaque objects in header files.
+
== Naming ==
-
In <code>header.h</code>:
+
C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like <code>ThisVariableIsATemporaryCounter</code>. A C programmer would call that variable <code>tmp</code>, which is much easier to write, and not the least more difficult to understand.
-
<c>typedef struct Foo Foo;</c>
+
''However'', while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function <code>foo</code> is a shooting offense.
-
In <code>source.c</code>:
+
''Global'' variables (to be used only if you ''really'' need them) need to have descriptive names, as do global functions. If you have a function that counts the number of active users, you should call that <code>count_active_users()</code> or similar, you should ''not'' call it <code>cntusr()</code>.
-
<c>#include "header.h"
+
Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder Microsoft makes buggy programs.
-
struct Foo { .. };</c>
+
''Local'' variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called <code>i</code>. Calling it <code>loop_counter</code> is counterproductive, if there is no chance of it being mis-understood. Similarly, <code>tmp</code> can be just about any type of variable that is used to hold a temporary value.
-
Then a user of <code>header.h</code> can declare:
+
If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See next section.
-
<c>Foo *foo;</c>
+
== Functions ==
-
but cannot access the contents of Foo. In addition, the user cannot declare a plain (non pointer) Foo, and so is forced to go through whatever allocation routines you provide. We encourage this modularity technique.
+
Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80×24, as we all know), and do one thing and do that well.
-
Don't mix declarations with type definitions; i.e., don't do:
+
The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's ok to have a longer function.
-
<c>struct Foo {
+
However, if you have a complex function, and you suspect that a less-than-gifted first year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely. Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance critical, and it will probably do a better job of it that you would have done).
-
    int x;
+
-
} object;
+
-
or
+
Another measure of the function is the number of local variables. They shouldn't exceed 5-10, or you're doing something wrong. Re-think the function, and split it into smaller pieces. A human brain can generally easily keep track of about 7 different things,
 +
anything more and it gets confused. You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now.
-
typedef struct {
+
== Commenting ==
-
    int x;
+
-
} type;</c>
+
-
All typedefs should stand out by themselves.
+
C-style comments only.
-
=== Structure fields ===
+
Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the ''working'' is obvious, and it's a waste of time to explain badly written code.
-
Declare each field of a structure on a line by itself. Take time to think about the order of the fields. Try to keep related fields grouped. Within groups of related fields, try and pick some uniform scheme for organizing them (e.g., alphabetically or by frequency of use). When all other considerations are equals, place larger fields first, as C's alignment rules may then permit the compiler to save space by not introducing "holes" in the structure layout.
+
Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to section 4 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it.

Current revision as of 14:17, 16 July 2010

This document gives coding conventions for the C code comprising many of DareNET's development projects.

Note, rules are there to be broken. Two good reasons to break a particular rule:

  1. When applying the rule would make the code less readable, even for someone who is used to reading the code that follows the rules.
  2. To be consistent with surrounding code that also breaks it (maybe for historic reasons) -- although this is also an opportunity to clean up someone else's mess.

In This Guide:

C dialect

  • While you may use C99, keep in mind that variable length arrays and macros with variable number of parameters are not well supported amongst most compilers. If you use these features, ensure you account for this (see services-darenet's HelpServ module for an example).
  • GCC is the compiler we use for almost all our testing. We recommend you use it as well. However, while use of GCC extensions are not prohibited, we don't necessarily encourage their use either.
  • Never use C++ style // single line comments.

Indentation

Tabs, tabs, ONLY tabs. Use one tab for each level of indentation. Spaces should ONLY be used for alignment, not indentation.

Preference: Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.

Braces

The other issue that always comes up in C styling is the placement of braces. Unlike the indent size, there are few technical reasons to choose one placement strategy over the other, but the preferred way, as shown to us by the prophets Kernighan and Ritchie, is to put the opening brace last on the line, and put the closing brace first, thusly:

if (x is true) {
        we do y
}

However, there is one special case, namely functions: they have the opening brace at the beginning of the next line, thus:

 int function(int x)
{
        body of function
}

Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are right and (b) K&R are right. Besides, functions are special anyway (you can't nest them in C).

Note that the closing brace is empty on a line of its own, except in the cases where it is followed by a continuation of the same statement, i.e. a "while" in a do-statement or an "else" in an if-statement, like this:

do {
        body of do-loop
} while (condition);

and

if (x == y) {
        ..
} else if (x > y) {
        ...
} else {
        ....
}

Rationale: K&R.

Also, note that this brace-placement also minimizes the number of empty (or almost empty) lines, without any loss of readability. Thus, as the supply of new-lines on your screen is not a renewable resource (think 25-line terminal screens here), you have more empty lines to put comments on.

Naming

C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand.

However, while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function foo is a shooting offense.

Global variables (to be used only if you really need them) need to have descriptive names, as do global functions. If you have a function that counts the number of active users, you should call that count_active_users() or similar, you should not call it cntusr().

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder Microsoft makes buggy programs.

Local variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called i. Calling it loop_counter is counterproductive, if there is no chance of it being mis-understood. Similarly, tmp can be just about any type of variable that is used to hold a temporary value.

If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See next section.

Functions

Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80×24, as we all know), and do one thing and do that well.

The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's ok to have a longer function.

However, if you have a complex function, and you suspect that a less-than-gifted first year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely. Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance critical, and it will probably do a better job of it that you would have done).

Another measure of the function is the number of local variables. They shouldn't exceed 5-10, or you're doing something wrong. Re-think the function, and split it into smaller pieces. A human brain can generally easily keep track of about 7 different things, anything more and it gets confused. You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now.

Commenting

C-style comments only.

Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the working is obvious, and it's a waste of time to explain badly written code.

Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to section 4 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it.