Permalink
Find file
Fetching contributors…
Cannot retrieve contributors at this time
64 lines (49 sloc) 1.66 KB
FAWN project code style guidelines:
Makefiles: Always use -Wall unless there's a documented reason
not to. Don't commit code that has compilation
errors or warnings.
File naming: C files: .c .h
C++ files: .cc .h
Indentation by example. Base 4 spaces:
if (test) {
....
}
else {
...
}
/**
* Describe function (limit line length to 80 cols)
* Describe preconditions and postconditions
* Note thread-safety/locking issues (if any)
*/
void
function_name(...)
{
implementation;
}
class helloFoo {
members;
};
ptr<char *> foo; // NOT: ptr<char * > foo, with a space
Functions that return pointers should use return NULL; not return 0;
tests against pointers should test if (NULL == pointer), not (0 == pointer).
Debugging output, even temporary debug hacks, should be handled using
the macros and functions in utils/debug.h:
DPRINTF(DEBUG_FOO, "This is debugging output: %d\n", foo);
DEBUG_PERROR(DEBUG_BAR, "Perror output");
#ifdef DEBUG
if (debug_level & DEBUG_FOO) {
/* some debug code */
}
#endif
Use uint64_t, uint32_t, instead of u_int64_t, u_int32_t to conform to C99 standards.
You must include <stdint.h> in the appropriate places for uint*_t to work everywhere.
For other things, see:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Code cleanliness tools:
Please consider periodically checking your code with
* cppcheck
* antiC (part of the "jlint" package).
Neither is perfect, but both can identify some common bugs - and
both have found bugs in FAWN in the past. They catch somewhat
non-overlapping subsets of bugs, so try to use both.