Skip to content

Library Guidelines

Public API

  • Minimize the public surface — expose only what consumers genuinely need.
  • Never break a published public API without a major version bump (semantic versioning).
  • No global mutable state; all dependencies injected via constructor or factory.
  • No side effects at import or load time.

Documentation

  • Every public symbol has a documentation comment (GoDoc, Doxygen, Javadoc).
  • Provide runnable examples in the documentation.
  • Document error conditions and what callers are expected to do with them.
  • Document an interface's externally observable contract only — behavior and guarantees a caller can rely on (ordering, blocking vs. non-blocking, what a failure return means) — never the concrete implementation strategy behind it (which data structure, which algorithm). This applies to word choice too, not just to what's explicitly stated: prefer "accepted"/"rejected" over "enqueued"/"dequeued" unless the interface's contract is specifically to be a queue.

Versioning

  • Follow semantic versioning: MAJOR.MINOR.PATCH.
  • Deprecate before removing; mark deprecated symbols and provide migration guidance.
  • Maintain a CHANGELOG.md generated from Conventional Commits (e.g., via git-cliff).

Testing

  • Achieve high unit-test coverage of the public API.
  • Include integration tests that exercise the library as a consumer would.
  • Test with multiple runtime versions if the library supports a version range.

Directives

  • Minimize public API surface; expose only what consumers genuinely need
  • Never break a published public API without a major version bump (SemVer)
  • No global mutable state; all dependencies injected via constructor or factory
  • No side effects at import/load time
  • Every public symbol has a documentation comment (GoDoc, Doxygen, Javadoc); provide runnable examples
  • Document error conditions and what callers are expected to do about them
  • Document an interface's externally observable contract (behavior, guarantees) only, never its concrete implementation strategy — including word choice (e.g. "accepted"/"rejected" over "enqueued"/"dequeued" unless queuing is itself the contract)
  • Deprecate before removing; mark deprecated symbols with migration guidance
  • High unit-test coverage of the public API; integration tests exercising the library as a consumer would
  • Test multiple supported runtime versions where the library supports a version range