MansOS Coding Standard

General guidelines

1. The world of miniature embedded systems has limited resources. Therefore, the code must be very efficient.
2. Provide easy to use and simple API. There are many users that are less than advanced in programming. In addition, but not at a great code expense, you may also provide advanced features for the professional developers.
3. Keep API short. That means less code and easier to understand.
4. When trading the data size with code size it is often better to keep the data smaller. Micro-controllers (MCU) tend to have more program memory than data memory.
5. When trading code size for execution time often it is better to reduce the code size at the expense of time, providing that the time increase is O(constant). Often the MCU have free execution cycles available.
   • Beware, however, that the increased execution time will burn more energy.
   • Beware also, that there might be sections of code where the short execution time is more important, for example, in the interrupt handlers.

General issues

Indentation

Do not use the TAB character for indentation, use spaces instead. Otherwise the code indentation may break when viewed by different developers. Use indentation at 4 spaces. You may find it useful to set TAB key to 4 spaces in your editor.

Size limits

Keep the line length under 80 characters to help the viewer and those that want to print your code. Break the line in several as necessary.

Functions in general should be no longer than ~50 lines (one screen). Functions that has only simple logic (e.g. initialization function) can be longer.

Try to not use too much levels of indentation - code is harder to read if there are too many.

Line endings

Always use UNIX-style line endings (newline charachter only). Avoid Windows-style line endings (newline + carriage return).

Use fromdos command line utility to convert files to the proper format, if necessary.

Cross platform code

Try to put all platform specific code in appropriate .h or .c files; avoid having #ifdef's in code, when possible.

Use:

// In pc/platfor_header.h:
#define PLATFORM_SPECIFIC_CONST 1
...
// In telosb/platfor_header.h:
#define PLATFORM_SPECIFIC_CONST 2
...
// In .c file:
a = PLATFORM_SPECIFIC_CONST;

Avoid:

// In .c file
#ifdef PC
a = 1;
#else
a = 2;
#endif

Inline functions

Linux coding style manual suggests that "a reasonable rule of thumb is to not put inline at functions that have more than 3 lines of code in them". For embedded systems this suggestion may be relaxed (to avoid function call overhead), but they should be kept at reasonable size.

Note! The compiler can make decision to inline even functions that are not declared as inlines, but only if the definition of that function is visible at the point where it is called.

Warnings

Do not ignore compilation warnings. Never commit code that compiles with warnings, unless you have a very good reason!

If there are really "invalid" warnings, it's better to disable them in Makefile than to ignore them.

Types

Constants and defines

Define constants with #define preprocessor directive or (preferred) as enum member.

The enum way is preferred because a symbol table entry is created in this way (can be useful for debugging), and the scope of the declaration is honoured.

Do no use const keyword, except in cases where it is really needed. const keyword should not be used, because in this way not only a symbol, but also a variable is always created. Note that this only applies to C, for C++ const can be used to make real constants.

Use all-uppercase names for constants, with underscore between the words.

Use:

#define DEFINE_A     123
#define DEFINE_B     1000000ul
#define DEFINE_FLAGS 0xEC
enum { DEFINE_C = 123 };

Avoid:

const unsigned VARIABLE_C = 123;

Avoid magic numbers. Use symbolic constants, defined in one way or another.

Integer types

Use only in integer types with explicitly specified size. This makes portability easier.

Use:

int8_t a;
uint32_t b;

Avoid:

char a;
unsigned long b;

Bool type

Use bool type where possible.

Comments

Respect the reader and write comments. In general, comment what your code does, not how.

Inline comments

Inside functions use comments only when necessary. In most cases, if you see some code that cannot be understood without commenting, that means you should rewrite it, not comment it!

Use descriptive function and variable names to reduce the need to comment your code.

Do not overcomment the code. Why? First, comments are not checked by compiler. That means they are often "broken" - invalid or out of date. Second, the more comments there are, the more difficult is to keep them up to date!

Comments in global scope

Describe what a function does before to it's prototype, unless that's obvious.

Example (quite obvious):

//
// Calculate greatest common divisor (GCD) of 'a' and 'b'
//
uint32_t gcd(uint32_t a, uint32_t b);

In general, there is no need to document function definitions. All exported functions should have prototypes anyway!

Preprocessor directives and comments

When using #ifdef or #if constructs, you should use comments for #endif if the code blocks are long enough. The comment for #endif should match the expression used in the corresponding #if or #ifdef. The comment for #else and #elif should match the inverse of the expression(s) used in the preceding #if and/or #elif statements.

 #ifdef MSP430
 /* msp430 stuff here */
 #else   // !MSP430 
 /* non msp430 stuff here */
 #endif  // MSP430 

Special comments

Use:

• XXX in comments to mark code that may not be strictly correct, but is working.
• FIXME in comments to mark code that does not work correctly.
• TODO in comments to mark places for not-yet-made features.

Syntax

Variable and function names

Variable names and function names shall start in lowercase and be written in CamelCase - writeByte, not write_byte, wrt_byte or WrItEbYtE.

 int writeByte;
 void printByte(void *buf);

Enums, structs and all other types

Use the first letter in uppercase, the rest is CamelCase. Add trailing "_t" to show this is a type, or "_e" to show this is an enum.

 typedef struct
 {
   int a;
   int b;
   int c;
 } MyStruct_t;

 typedef enum 
 {
   RECTANGLE, 
   CIRCLE = 17,
   LAST              // Use "Last" as the last enum available, as needed
 } ShapeType_e;

Enumeration values all should be written in uppercase.

Code control structures

Using braces

Place brace in the same line for short functions (3 lines or less), and place braces in next line for long functions.

Use:

void shortFunction(void) {
   doThis();
   doThat();
}

void longFunction(void)
{
    doSomething();
    doSomethingElse();
    // ... 10 more lines ...
}

Always use braces after if(), else, for(), while(), do, even when there is only one statement in the block. There might be a few exceptions when if and the statement is on the same line and unmistakeably has one simple statement such as an assignment.

You may write the opening brace on the same or the next line. Use common sense. Generally to make a short if() with just one statement in the body I use it on the same line.

Use:

 if (17 == a) b++;

 if (...) {
     foo();
 }

 if (...)
 {
     foo();
     bar();
 }

Avoid:

if (foo)
    bar();

This should be avoid because the code is harder to modify (e.g. add more statements insides the body of the if statement) in the future; and because the code flow may be unclear in some cases.

switch statement

In all places where break keyword is not being used by intention, a /* falls through */ comment should be inserted.

Example:

switch (condition) {
case A:
    if (x == 13) return 5;
    // falls through
case B:
case C:
    return 6;
}

Spacing in expressions

Use space to separate tokens in expressions and braces everywhere in the code. However, you may use no space between unary operation and operand, for example, i++;

 x = y + 16 - z++;

 if ( 17 == a ) {
     b = foo( c, d );
 }

Use spaces before braces with if, for, while.

Do not use space before braces in foo() (i.e. function calls).

Use spaces around binary and ternary operators:

x = a ? b + c : d;

Variable initialization

No explicit global variable initialization to zeros need, because by C standard all static variables (including global) are by default initialized to zero.

Use:

uint8_t array1[10] = {0};        // all members set to zero
uint8_t array2[10];              // all members set to zero by default
uint8_t array3[10] = {1, 2, 3};  // all except first three members set to zero by default
int someInteger;                 // 0 by default

Avoid:

uint8_t array[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
int someInteger = 0;

If for some reason you want to avoid initalization, use "noinit" attribute. For example, this may be need for large arrays, because apparently the initialization can take long enough time for watchdog timer to expire!

Example:

uint16_t array[500] __attribute__((section (".noinit")));

For some compilers there is __no_init keyword that does the same:

__no_init uint16_t array[500];

Structures can be initialized like this:

typedef struct {
    uint16_t i;
    int8_t c;
    uint8_t a[3];
} SomeStruct_t;

SomeStruct_t var1 = {123, 'a', {1, 2, 3}};
SomeStruct_t var2 = {123}; // member 'i' is 123, all other members are implicitly initialized to 0

Or (the preferred way):

SomeStruct_t var3 = {
    .i = 123,
    .c = 'a',
    .a = {1, 2, 3}
};

Include paths

All internal MansOS code should use include paths with directory explicitly specified. Use:

#include <lib/dprint.h>

Avoid:

#include <dprint.h>
#include "dprint.h"

This is not a requirement for application code!

This is also not a requirement if the included file is under arch directories, because in this case the path is platform specific. Because of this, it is recommended to add _hal suffix in those filenames, for example, radio_hal.h.

Conclusion

Remember that rules are made to be broken; do not follow them blindly!