0x0 Style Guide

This guide defines public source style for 0x0 docs, examples, libraries, and

apps.

Naming

Public function names use lowercase kebab-case:

(ƒ parse-option ...)
(ƒ safe-path ...)

Do not use underscores in function names:

some_method

Allowed exceptions:

• external protocol names that must preserve wire spelling;
• compatibility package directory names such as jmp0x1b_*;
• generated metadata files where the source format already requires another

spelling;

• app or deployment file names that are not 0x0 function names.

Files And Modules

• Source files end in .0x0.
• Library source lives at libs/<name>/src/lib.0x0.
• Library smoke tests live at libs/<name>/tests/smoke.0x0.
• Module names should be stable and descriptive.
• Examples should state expected output in the file header comment.

Public Functions

Public library and framework functions should include:

• ∷ type annotation when the current checker can validate the contract;
• cap annotation when the function is meaningfully pure or effectful;
• doc annotation for generated API docs.

Comments

Use comments for intent, representation, invariants, ABI rules, and non-obvious

control flow. Avoid comments that restate the next expression.

Capabilities

Use the narrowest capability that matches the implementation:

• pure for deterministic helpers;
• file for file wrappers;
• network and process only for runtime/framework boundaries where the

current docs support that boundary;

• io for ordinary effectful code when no narrower capability applies.

Public Documentation

Docs must describe implemented behavior. Planned and deferred work must be

visibly labeled.