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.

Functions

• Only use the anonymous argument form (fun | pat => exp ...) when there is exactly one input to the function.

Type Definitions

• 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.

Modules

• 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.

Expressions

• 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.