> Our design goals are safety, performance, and developer experience. In that order.

> Contrary to popular belief, simplicity is also not the first attempt but the hardest revision

> code, like steel, is less expensive to change while it's hot.

== Safety
[[https://spinroot.com/gerard/pdf/P10.pdf|NASA's Power of Ten — Rules for Developing Safety Critical Code]]
* Use only very simple, explicit control flow for clarity.
* Put a limit on everything. [[https://en.wikipedia.org/wiki/Fail-fast_system|Fail Fast]]
* Assertions detect programmer errors. The only correct way to handle corrupt code is to crash.
* Assertions are a safety net, not a substitute for human understanding. 
** Build a precise mental model of the code first.
** encode your understanding in the form of assertions,
** write the code and comments to explain and justify the mental model to your reviewer,
** and use VOPR as the final line of defense, to find bugs in your and reviewer's understanding of code.
* No memory may be dynamically allocated (or freed and reallocated) after initialization.
* Declare variables at the smallest possible scope, and minimize the number of variables in scope.
* Good function shape is often the inverse of an hourglass: a few parameters, a simple return type, and a lot of meaty logic between the braces.
* Centralize control flow. When splitting a large function, try to keep all switch/if statements in the "parent" function, and move non-branchy logic fragments to helper functions.
* Centralize state manipulation. Let the parent function keep all relevant state in local variables, and use helpers to compute what needs to change, rather than applying the change directly.

== Developer Experience
* Add units or qualifiers to variable names, and put the units or qualifiers last, sorted by descending significance. `latency_ms_max` rather than `max_latency_ms`.
* Callbacks go last in the list of parameters.
* Order matters for readability (even if it doesn't affect semantics). On the first read, a file is read top-down, so put important things near the top. The main function goes first.
* Don't overload names with multiple meanings that are context-dependent.