| 2 | |
| 3 | == Mandatory coding practices == |
| 4 | |
| 5 | These are absolutely required for any contribution. |
| 6 | |
| 7 | * Adhere to the [wiki:CStyle coding style standard] |
| 8 | * Document your code |
| 9 | * Doxygen and regular comments |
| 10 | * Adhere to RCS rules from the very beginnning |
| 11 | * Use Bazaar for revision control |
| 12 | * Separate into reasonably-sized changesets |
| 13 | * Changeset comments must be complete, descriptive English sentences, typically in infinitive/imperative tense |
| 14 | {{{ |
| 15 | Example: Fix DNS resolution not working due to missing local address. |
| 16 | }}} |
| 17 | |
| 18 | == Recommended coding practices == |
| 19 | |
| 20 | Good coding practices that are highly recommended (but cannot be mandatory, since they're not necessarily measurable). |
| 21 | |
| 22 | * Principle of least surprise |
| 23 | * Comments are good, but code should be self-explanatory |
| 24 | * Optimize code for understandability |
| 25 | * Separation of concerns, divide et impera |
| 26 | * Separate code into small modules, functions with well-defined interfaces ([https://www.youtube.com/watch?v=heh4OeB9A-c 1]) |
| 27 | * Unit testing |
| 28 | * Design for testability ([https://www.youtube.com/watch?v=acjvKJiOvXw&list=PLvqMob1eOxGIW51K9PA_N4u2MJbddNw-H 2]) |
| 29 | * Every non-trivial module should have carefully written unit tests (PCUT) |
| 30 | |
| 31 | == Resources on Good Coding Practices == |
| 32 | |
| 33 | * 1. [https://www.youtube.com/watch?v=heh4OeB9A-c How To Design A Good API and Why it Matters (video)] |
| 34 | * 2. [https://www.youtube.com/watch?v=acjvKJiOvXw&list=PLvqMob1eOxGIW51K9PA_N4u2MJbddNw-H Design Tech Talk Series Presents: OO Design for Testability (video)] |