Code Quality

This page defines coding and testing standards for contributions to navigate.

Coding Style

Naming Conventions

We follow PEP 8. Class names use CamelCase and variables/functions use lowercase_with_underscores.

Type Hints

Type hints are used throughout the code base. Add type hints to new methods and functions. If needed, see PEP 484.

Docstrings

Use numpydoc formatting guidelines for docstrings.

Documentation Compatibility

Use Sphinx-compatible docstrings and formatting. For examples, see the Sphinx NumPy docstring example.

Formatting and Linting

• Use Black for formatting.

• Use Ruff for linting.

• Run both via pre-commit run --all-files before opening a pull request.

In rare cases, a targeted # noqa is acceptable. For example:

from navigate.model.device_startup_functions import start_stage
device_name = "stage"
exec(
    f"self.{device_name} = start_{device_name}("
    "name, device_connection, configuration, i, is_synthetic)"
)

from navigate.model.device_startup_functions import start_stage  # noqa

Testing

All new or changed behavior should include tests to prevent regressions and document expected behavior.

• We use pytest for unit tests.

• Use existing tests in test/ as style examples.

• Run pytest locally before submitting a pull request.

Configuration Dictionary Parsing

The configuration file is loaded as a large dictionary object. Use .get() with defaults where appropriate to reduce key errors and improve fallback behavior.

# Galvo waveform information
self.galvo_waveform = self.device_config.get("waveform", "sawtooth")