These conventions are not yet adhered to by the Sunflower implementation, portions of which date from 1999. Please however do adhere to it for all new code.
To see a recent pull request that applies some of these rules to cleaning up code, see the pull request for issue #132.
- Code indented with tabs, not spaces. If you use
vim
, set your.vimrc
as follows so you can see where you have stray spaces:
set list
set listchars=tab:>-
For visual alignment, assume the code will be viewed in an editor where tabs are rendered to be as wide as eight spaces.
-
Variable names in
camelCase
. -
Type names begin with a capital. Type names specific to Sunflower begin with
Sunflower
, e.g.,SunflowerSymbolType
. -
Constant names and enum entries begin with
kSunflower
, e.g.,kSunflowerIrNodeType_PintegerType
. -
C-style comments, in the form:
/*
* Comment (offset with a single tab)
*/
-
Comments are not just "notes to self". They should provide useful explanatory information.
-
No
#include
within header .h files if possible. -
No function definitions in header .h files.
-
Files named named module
<sunflower>-camelCasedModuleName
, e.g.,sunflower-xxxcamelCasedName.c
. -
Constants in
enum
s, not in#define
s where possible. -
Avoid
#define
if possible. -
All
if
statement followed by curly braces, even if body is a single statement. -
The pattern
\t\n
(tab followed by newline) should never occur in a source file. -
Except for temporary debugging statements, all print statements should use
flexprint
from thelibflex
library (https://github.com/phillipstanleymarbell/libflex). This allows us to buffer print statements and makes the web interface/demos and other deployments possible. Errors go into the bufferFperr
and informational output (almost everything that is not an error) goes intoFpinfo
. We sometimes have additional dedicated buffers to isolate certain outputs.