Developer's Guide

Developer’s Guide

Please heed the following guidelines when submitting code to Hax. Remember that consistency is key when working on a project with multiple developers.

Whitespace

One tab should be used for each level of desired intention at the beginning of each line. When editing a file you can set your tab-size as desired, but insure that no line exceeds 80 characters in width with 8-space tabs. All alignment other than indention should be done with spaces. Never commit code with trailing whitespace.

Brace Style

All control constructs except one-line if statements followed by continue, break, or return should use braces. The opening brace is to be placed one space after the closing parenthesis of the control structure and the closing brace should be on its own line, left-aligned with the beginning of its control structure.

Proper Brace Style

void foo(int error, int i, int n)
{
	if (error)
		return -1;

	for (i = 0; i < n; ++i) {
		printf("%d\n", i);
	}

	for ( ; i != 0; i--, error--)
		;
}

Functions

Functions should be all-lowercase with words separated by underscores (i.e. follow the Unix Hacker naming style). Ideally, a function should consist of one or more nouns followed by a verb. Related functions are to be spatially grouped in header files and should start with a common prefix. See the digital_*() family of functions in hax.h for an example of such a grouping. Helper functions that do not appear in a header file must be declared static to prevent linking conflicts.

Types

Since the PIC is an 8-bit processor and the Cortex is a 32-bit processor, always use the types defined in stdint.h and avoid referring to types by their normal names (e.g. int, long). Custom types (i.e. typedef`s) should be suffixed with `_t and be avoided at all costs. Only consider using a custom type if it is only referenced by value internally and is completely opague to user-code. See index_t for such an example.