On TigerStyle

https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md

• Declare variables at the smallest possible scope, and minimize the number of variables in scope, to reduce the probability that variables are misused.

100%

• Functions should fit on the screen (short functions)

100%. It mentions a limit of 70 lines. This is long in my opinion. There is a good remark in hackernews comment:

Focus on separating pure code from stateful code, that’s the key to large maintainable software! And choose composability over inheritance.

This is a good insight. Separating big code into smaller pieces should not be done arbitrarily. This topic deserves a dedicated article.

• 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. Divide responsibility. All control flow should be handled by one function, the rest shouldn’t care about control flow at all. In other words, “push ifs up and fors down”.

Mostly agree, but I wonder about the tension of consolidating complex control flow in a single function vs dividing it into more digestible smaller pieces. I suppose it is a matter of identifying appropriate abstraction layers. if the control flow belongs on the same layer, it is logical for it to be centralized.

• Similarly, 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. Keep leaf functions pure.

100%. Separate Calculating From Doing

• Negations are not easy! State invariants positively. When working with lengths and indexes, this form is easy to get right (and understand): if (index < length) instead of `if index >=length)

I like this insight. It is commonly suggested that conditionals should be positive rather than negative, but this is the first time I hear it w.r.t. invariants.

• All errors must be handled. An analysis of production failures in distributed data-intensive systems found that the majority of catastrophic failures could have been prevented by simple testing of error handling code. > “Specifically, we found that almost all (92%) of the catastrophic system failures are the result of incorrect handling of non-fatal errors explicitly signaled in software.”

100%. A strong motivation for explicit error handling using std::expected<T,E> or similar, over using exceptions.