rotorflight-firmware — Cursor Rules

Rotorflight uses both GitHub pull requests (with CodeRabbit) and local reviews in Cursor. All changes MUST follow this review workflow: • Before opening a PR • Ensure the code compiles with all warnings treated as errors (-Werror). • Run any relevant local tests or bench checks (for example, sensor initialisation, arming, basic spool-up on the bench). • Update Changes.md when required (CLI, MSP, default values). • Fill in the PR description with: • A short, clear summary of the change. • Whether the change is flight-critical (affects control loop, sensor pipelines, failsafes, arming logic, power management or timing). • Testing performed (for example, "bench only", "hover test", "full flight test", including heli type if relevant). • PR scope and focus • Each pull request MUST have a clear, limited scope and title that reflects it. • Do not mix unrelated changes in the same PR (for example, combining PID logic changes with OSD cosmetic tweaks). • Do not change unrelated files "while you are there" (for example, drive-by formatting or renaming) unless: • They are strictly necessary for the main change (for example, shared API changes), and • This is clearly explained in the PR description. • If you discover an unrelated issue while working on a PR, open a separate PR (or at least a separate commit and follow-up PR) rather than bundling it in. • GitHub + CodeRabbit review • CodeRabbit is used to provide first-pass automated review and highlight potential issues. • Human maintainers are responsible for final decisions, especially for flight-critical code. • If CodeRabbit flags style issues in legacy files, prefer matching the existing style unless performing a larger refactor. • Treat all CodeRabbit findings as suggestions that must be either: • Fixed, or • Explicitly acknowledged and justified in the PR discussion. • Local Cursor reviews • Use Cursor to: • Inspect complex logic, invariants and interactions between modules. • Check for hidden assumptions and edge cases (overflow, timing, race conditions). • Help reason about refactors, but do not rely on Cursor alone for flight-critical sign-off. • Always re-read the final diff yourself with the checklist below before merging.

This is the Rotorflight Flight Controller Firmware - a safety-critical embedded C project for single-rotor RC helicopters, forked from Betaflight 4.3. Code quality and consistency are paramount for flight safety.

Use these rules with Rotorflight specific files and any new files. With existing legacy files, follow the existing coding style. • Target C standard: C11 (or C99 where explicitly required) with no variable-length arrays and no dynamic memory allocation.

• ALWAYS use 4 spaces for indentation - Never use tabs • Maximum line length: 120 characters • Trailing (invisible) white space is not allowed • Use blank lines sparingly: • One blank line between code blocks is preferred • Two blank lines can be used between separate sections of code • Three or more blank lines are not allowed • Use a hybrid K&R/Allman brace style: • Allman for function definitions • K&R for control structures • Use consistent spacing • function calls: `c doSomething(var1, var2); ` • function definitions: `c void myFunction(int x, data_t *data) { ... } ` • if and while statement: `c if (condition) { ... } ` • for statement: `c for (i = 0; i < 10; i++) { ... } ` • switch statement: `c switch (var) { case 0: ... break; case 1: ... break; default: break; } ` • assignment: `c a = 10; ` • increment and decrement: `c a++; b--; ` • math operators: `c a = (b + 8) * 10; `