Code Style Guide

Warnings

Don't leave any warnings. If necessary, you can suppress a warning by putting the [@warning "-#"] annotation narrowly on the node generating the warning, where # is the warning code. Leave an explanation for why that annotation is necessary when you do so.

Only use the anonymous argument form (fun | pat => exp ...) when there is exactly one input to the function. Otherwise, name all of the arguments and then switch on the intended argument, even if it happens to be the last one in the argument list.

Each type should have its own module, even if it is small.
Whenever possible, place [@deriving sexp] on type definitions, which will automatically derive sexp serializers. This will generally require an open Sexplib.Std at the top of your module to open the standard sexp serializers for base types like string and int.
List the preferred variable prefixes with a comment of the form /* Variable: <preferred> */ before the type definition.

Each module should have its own .re file.
Each module should have a corresponding signature (.rei) file if there are any top-level local definitions.
Local definitions should be fully type annotated.
Use open sparingly, and as narrowly as possible. Prefer using type annotations so that type inference can discover which constructor you mean from context.

Make sure you are using the preferred variable prefix for the type of the variable, if it is listed on the type definition (see above).
Prefer numeric suffixes for different values of the same type in the same scope, e.g. e1, e2, e3, rather than e, e',e''.
When working with something that has functional state, use the same variable name every time the state updates. For example, use u_gen for all MetaVarGen.t values rather than u_gen, u_gen', etc. This ensures that you do not accidentally use a stale state.