How to structure nested module documentation#
This guide shows a clear pattern for documenting modules with nested types, procedures, and members.
Define entities inside f:module#
Put related directives inside the module body. sphinx-ford then builds
fully qualified names automatically (for example my_module.compute).
.. f:module:: my_module
:permission: public
Module description.
.. f:function:: compute(x, y)
:param x: Input x
:ftype x: real
:intent x: in
```{f:module} my_module
:permission: public
Module description.
```{f:function} compute(x, y)
:param x: Input x
:ftype x: real
:intent x: in
```
```
This renders as:
Document members and bound procedures in f:type#
Use f:member for type components and f:boundproc for bound
procedures.
.. f:type:: config_t
:extends: base_t
.. f:member:: verbose
Enable verbose output.
.. f:boundproc:: validate
:deferred:
Check configuration consistency.
```{f:type} config_t
:extends: base_t
```{f:member} verbose
Enable verbose output.
```
```{f:boundproc} validate
:deferred:
Check configuration consistency.
```
```
This renders as:
Set context across split files with f:currentmodule#
If module content is split across files, set context without emitting new output.
.. f:currentmodule:: my_module
:f:func:`compute` now resolves to ``my_module.compute``.
Use ``None`` to clear the context.
.. f:currentmodule:: None
```{f:currentmodule} my_module
```
{f:func}`compute` now resolves to `my_module.compute`.
Use `None` to clear the context.
```{f:currentmodule} None
```
This renders as
computenow resolves tomy_module.compute.Use
Noneto clear the context.