Skip to content

Coding Standards and Guidelines

This page keeps contributor expectations compact and implementation-focused.

Working Principles

  • keep route handlers thin
  • keep analytical logic separately callable
  • use stable names for fields, identifiers, and datasets
  • document real entry points, not idealized ones
  • prefer adding the next useful docs link whenever a page could become a dead end

Code Structure Preferences

  • isolate the data-processing function
  • keep IO and publication helpers near the boundary
  • make local execution possible before async integration
  • normalize request fields consistently
  • keep validation and response behavior explicit
  • push heavy work out of the HTTP layer
  • link to actual files or routes
  • show at least one practical example
  • point to the next deeper page, one neighboring page, and one action page

Naming

Use consistent names across code, metadata, and docs:

  • Computing API, not Internal API
  • Developers, not Builders
  • Installer, not Interactive Installer

For field and dataset naming, continue into Standardised Field / Constant / Variable Names.

From here, the usual next step is Build New Pipelines if you are extending the stack, or Contributing if you are preparing a change for review.