Welcome to Orbital's OBC Firmware Onboarding Challenge! Please visit this Notion doc for the challenge instructions. Remember to follow our style guide which is written below.
Variable and function names should be descriptive enough to understand even without comments. Comments are needed to describe any complicated logic. You may use //
or /* */
for single line comments.
Function comments should exist in both the .h and .c files optimally, but at minimum they should be available in the .h files. Comments should follow the format shown below:
/**
* @brief Adds two numbers together
*
* @param num1 - The first number to add.
* @param num2 - The second number to add.
* @return uint8_t - Returns the sum of of the two numbers.
*/
uint8_t add_numbers(uint8_t num1, uint8_t num2);
- File comments are not required
- The symbol name should have the form
<PATH>_<FILE>_H_
For example, if the file is abc/xyz/foo.h
, then the header guard should be
#ifndef ABC_XYZ_FOO_H_
#define ABC_XYZ_FOO_H_
...
#endif
variableNames
in camelCasefunctionNames()
in camelCaseCONSTANT_NAMES
in CAPITAL_SNAKE_CASEfile_names
in snake_casetype_defs
in snake_case with _t suffix- Ex:
typedef struct { int a; int b; } struct_name_t
- Ex:
- 4 spaces per level of indentation
- Use spaces before opening brackets for conditionals and loops (e.g.
if ()
andwhile ()
), but not for function calls (i.e.my_func()
). - Operators:
- No spaces around
*
,/
,%
,!
- One space on either side of
=
,==
,+
,-
,+=
,-=
, etc - One space after every comma
my_func(var1, var2, var3)
- No spaces around
- Import statments should be grouped in the following order:
- Local imports (e.g.
#include "cc1120_driver.h
) - External library imports (e.g.
#include <semphr.h>
) - Standard library imports (e.g.
#include <stdint.h>
)
- Local imports (e.g.
- 160 character limit per line (not a hard limit, use common sense)
- Hanging indents should be aligned to delimeter:
myFunction(hasToo,
many, variables)
- Avoid complex flow constructs, such as goto and recursion.
- All loops must have fixed bounds. This prevents runaway code.
- Avoid heap memory allocation.
- Use an average of two runtime assertions per function.
- Restrict the scope of data to the smallest possible.
- Check the return value of all non-void functions, or cast to void to indicate the return value is useless.
- Limit pointer use to a single dereference, and do not use function pointers.
- Compile with all possible warnings active; all warnings should then be addressed before release of the software.