-
Notifications
You must be signed in to change notification settings - Fork 20
Mooltipass Team Ground Rules
We all have differents way to think of how a particular feature should be made. As a consequence, the team relies on collective wisdom to pick the way we implement each functionality. This will be done via Google group discussions, and may be pushed to the general Mooltipass mailing list if a strong difference of opinions happen.
Obviously this doesn't apply to trivial things, only to things that impact the global firmware architecture.
We keep track of all changes that were made to the mooltipass source code and individually approve each change that will be applied to it.
We don't want several contributors changing at the same time a particular file, which would result in merge conflicts.
We will not approve non documented code on github. Here is a simple example of correct documenting:
/** Current detection state */
volatile uint8_t button_return;
/*! \fn security_code_validation(uint16_t code)
* \brief Check security code
* \param code The code
* \return success_status (see enum)
*/
RET_TYPE security_code_validation(uint16_t code)- 4 spaces, no tabs
- snake case naming for functions and global variables
- defines in uppercase
- function names and global variables should be prepended by the file name it is in
- 80 chars limit is not needed (we're not in 1980 anymore!)
- a given function should not be more than 100 lines long (exceptions may happen)
- comment your code
- no magic numbers
- no mallocs