2.9 KiB
Coding Standard
General
We are aiming for a minimum of C99 support. A script in
extra
can be found called astyle.sh
. This uses
the Linux tool Artistic
Style to enforce coding standards.
Coding Style
Everyone has a preferred coding style, there is no real correct style. What is important is that we stick to one style throughout the code.
We should use a variant of the Allman coding style. The variation is to use 2 spaces instead of tabs. The exception to the rule is Makefiles where space indentation can break them.
Allman style specifies that braces associated with a statement should be on the following line with the same indentation and the statements inside the braces are next level indented. The closing braces are also on a new line at the same indentation as the original statement.
For example:
while (x == y)
{
();
something();
somethingelse}
(); finalthing
Types
Use C99 types (where possible), this will very much help us to find conversion bugs. So:
- Use bool, not my_bool.
- Use true and false, not TRUE and FALSE (those macros need to die).
- ulong → uint32_t
- ulonglong uint64_t
- long int → int32_t
The keyword NULL
should always be used when referring to the pointer NULL
Allocation
For performance reasons we should try to limit the number of times we allocate and deallocate memory. Do not do thousands of allocates and deallocates to save 32k of RAM.
Naming style
Variable names
Variables should be verbosely names, no caps, underscores with
spaces. Do not just use i
in for loops, again we have
developers with bad eyes.
Types
New types should use the _t
postfix. Private structs
should be typedef'ed and also use this.
Public Structs
Public structs should be typedef'ed and use the _st
postfix
Conventions
- use column instead of field
- use schema instead of database
Include Files
Includes that will be installed need to be written like:
#include <drizzled/field/blob.h>
The following should only be used in cases where we are to never install these libraries in the filesystem:
#include "item.h"
Comments
Where it is not obvious what is going on. Hopefully most of the code will be self-commenting.
All code should have license headers.
Comment blocks should use the format:
/* Comment Block
* This is a multi-line comment block
*/
C99 style in-line and single line comments are allowed for small comments
// small comment
Line lengths
Whilst there is no hard limit on line lengths it is recommended that lines stay under 80 characters unless going above this increases readability of the code.