7.10 File Headers and Inline Documentation [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 7.10 File Headers and Inline Documentation ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:07-naming-and-file-conventions:start | Return to Naming and File Conventions ]]

The team should consistently document handwritten [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]]. File headers and inline documentation help developers and reviewers understand why an Artifact exists, how it participates in Phase 0, and whether it is handwritten, generated, or [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]]-driven.

Every handwritten source file and script should include a short header that identifies the Artifact’s purpose, its role in the Phase 0 [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]], and any important usage constraints. Generated files should include a generated-file warning where the generator or file format permits it.

Language-specific documentation conventions should follow the normal practice of the language or file type:

  - Java source should use Javadoc for public classes and methods.
  - Python source should use module, class, and function docstrings.
  - JavaScript source should use JSDoc for public interfaces.
  - TypeScript source should use TSDoc or JSDoc for public interfaces.
  - Bash scripts should use a script header block and short comments before non-trivial functions.
  - [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] files should use comment blocks to explain structures, fields, and topic-facing types.
  - YAML, XML, and other Configuration files should use header comments where the format permits comments.
  - Markdown files should begin with a clear title and a short purpose statement.

Documentation should explain purpose, assumptions, inputs, outputs, [[dido:99_annexes:annex-b-terms-and-definitions:l:lifecycle|Lifecycle]] effects, exceptions, exit codes, generated status, and Configuration dependencies where those details matter. Documentation should not repeat obvious code. The goal is to make the implementation reviewable and maintainable, not to create noise.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>