Write an eventuals style guide to document best practices when writing code that uses eventuals

[CodingCanuck]

Code written using eventuals often looks very different from "normal" C++ code. For example, function definitions typically live in header files rather than .cc files, method return types are usually auto, expression are very long with deep indentation, etc.

Let's write something like a style guide that users of eventuals can turn to to write high quality code using the eventuals library. This could contain best practices for users to write code that's readable, maintainable, and performant.

Example topics we might want to start with:

• Should class method definitions be inline (discouraged in normal C++) or separated from the declaration?
• When is it wise or unwise to use Task or other forms of type erasure?
• What does testable eventuals code look like? (Does this mean classes with virtual methods to enable the use of test doubles in unit tests, and does that in turn require using Task as the return type?)
• How can users mitigate the readability hit from having to use auto for most method return types (e.g. use TypeCheck<ReturnType> liberally)?
• Should you prefer few eventuals with large bodies, or a long chain of small eventuals? (Does one compile faster, or have other maintainability benefits)
• Any tips for effectively handling the pages and pages of compiler output when getting an eventuals method to compile (e.g. maybe prefer many small standalone methods that you can compose together, and get each one compiling seprately)?