Don't go too deep without exposing and sanity checking your approach with the user. Reveal your thinking and processing as much as possible!
Don't worry about linting errors if ruff check --fix and ruff format will fix them.
But do not run any of the linter checks on the terminal yourself, I'll handle that.
Write docstrings for public functions/methods.
For functions, they should be on this format
"""<short description>
<optional long description>
Args:
arg1: <description>
arg2: <description>
Returns:
<description>
<description>
"""
Never say types in descriptions, as they are already annotated. Mention the shape of all numpy arrays. Try not to duplicate information inside the docstring too much, and don't just repeat the variable names.
Never modify the stubs. They are autogenerated, and your changes will just be overwritten.
Keep comments minimal, only add comments when the code needs explaining why it's doing something.
Prefer early returns or early continues over nested conditionals when it keeps the main path flatter and easier to read. Do not contort code just to avoid nesting, but avoid pyramid-shaped control flow.
Do not use ternary expressions. Use explicit if/else statements instead.
Name pose/transform variables exactly with the A_from_B convention, where the
transform maps coordinates from frame B into frame A. Avoid vague names like
pose for transforms unless the code is generic over frames.
Follow the color scheme of the existing plots in the plots.py file.
Making the type checker happy is less important in the plots if the plotting library APIs make it hard to make the types work. In this case the usage of type: ignore is fine.
All plots should be exported, and if applicable, have a matching method on the CalibrationResult object in calibrate.py.