WITH’s Coding Guidelines¶
Introduction¶
As you are part of WITH, you are not an individual developer but rather you take your place in a team that works together in numerous ways. Because no one is perfect, no project is ever finished and no requirement is set in stone, we ought to work in a way that acknowledges the reality of our mission. The present document explores the techniques to get as close as possible to this goal.
Warning
This document will hurt your feelings. But the main rule is: no exceptions. If you think that 2 spaces is inherently better than using 4 spaces, you can do it whichever way you want on your personal projects but here you must think of what happens when you’re sick and that someone must jump into your project at the last minute without any prepartion. Your job is complicated as it is, let’s focus your brain power on writing code and not on personal style.
Note
That said, this document is hosted in Git. If you feel like the rules should change don’t hesitate to talk about it and to submit a pull request!
Mandatory content¶
This content contains the explicit rules of what needs to be done within the WITH team and must be read and known by all.
Bonus material¶
This track of pages contains articles that are interesting for your reading and probably worthy of your consideration, but not required as part of the onboarding process.
- Common Pitfalls
- NASA’s power of 10
- 1. Avoid complex flow constructs, such as goto and recursion.
- 2. All loops must have fixed bounds. This prevents runaway code.
- 3. Avoid heap memory allocation.
- 4. Restrict functions to a single printed page.
- 5. Use a minimum of two runtime assertions per function.
- 6. Restrict the scope of data to the smallest possible.
- 7. Check the return value of all non-void functions, or cast to void to indicate the return value is useless.
- 8. Use the preprocessor sparingly.
- 9. Limit pointer use to a single dereference, and do not use function pointers.
- 10. Compile with all possible warnings active; all warnings should then be addressed before release of the software.
- Key takeaways
- Bugs
- The Async Debounce pattern
- Exceptions handling