Development Team/Coding Standards/new

Comments

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.

That being said, good places to put comments are:

• a broad overview at the beginning of a module
• 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.

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.

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.

Examples:

/* single line comments look like this */
 
/*
 * Important single line comments look like multi-line comments.
 */
 
/*
 * 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 */
 
/**
 * This is a doxified comment.
 */

The opening / of all comments should be indented to the same level as the code to which it applies, for example:

if (fubar()) {
	/*
	 * Fouled up beyond all recognition.  Print a nastygram
	 * and attempt to clean up.  If that doesn't work,
	 * die horribly, and try to crash the system while
	 * we're at it.
	 */
	...
}

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:

printf("hi\n");		/* hello revisited */

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?

Declarations and Types

Provide typedefs for all struct and union types, and put them before the type declarations. Creating the typedef eliminates clutter of extra struct and union 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.

Examples:

typedef struct Foo Foo;
typedef struct Bar Bar;
 
struct Foo {
    Bar *bar;
};
 
struct Bar {
    Foo *foo;
};

This gives a particularly nice scheme of exporting opaque objects in header files.

In header.h:

typedef struct Foo Foo;

In source.c:

#include "header.h"
 
struct Foo { .. };

Then a user of header.h can declare:

Foo *foo;

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.

Don't mix declarations with type definitions; i.e., don't do:

struct Foo {
    int x;
} object;
 
or
 
typedef struct {
    int x;
} type;

All typedefs should stand out by themselves.

Structure fields

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 equal, 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.