Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/PX4/PX4-Autopilot/llms.txt

Use this file to discover all available pages before exploring further.

PX4 uses the Google C++ Style Guide as its baseline, with a small set of project-specific modifications. Formatting is enforced automatically in CI — pull requests that fail the format check are not merged. Run the format tools locally before pushing to avoid round-trips.
Not all existing PX4 source code matches the style guide. You are only required to style the code you write or modify. You do not need to reformat an entire file when you touch one function.

​
Running format checks locally

Use these two targets to check and fix formatting on changed C/C++ files: 
make format          # auto-format changed C/C++ files
make check_format    # check only — exits non-zero if formatting is needed (CI uses this)
Run make format on every changed file before committing. If make check_format exits with a non-zero status, CI will reject your pull request.
Format changes are noisy in code review. Commit them separately from logic changes using style(scope): apply clang-format so reviewers can focus on the substance of your PR.

​
Key style rules

The following rules differ from or extend the Google C++ style guide:

​
Indentation

void doSomething() {
	if (condition) {  // tab character for indentation
		doWork();
	}
}
  • Tabs for indentation (equivalent to 8 spaces in display width).
  • Spaces for alignment (e.g., lining up values after a tab-indented line).

​
Line length

Maximum line length is 140 characters. Lines that exceed this will be flagged by check_format.

​
File extensions

Use .cpp for C++ source files, not .cc.

​
Naming conventions

ConstructConventionExample
Functions and methodslowerCamelCase()computeAltitude()
Classes and constructorsUpperCamelCase()EkfInterface()
Private member variables_underscore_prefixed_snake_case_private_member_variable
ConstantskUpperCamelCasekConstantFloat

​
Class access keywords

Place public:, protected:, and private: with zero spaces of indentation inside the class body: 
class MyClass {
public:
	float doSomething(const float input_param) const;

private:
	float _private_member_variable{0.f};
};

​
Documented code snippet

The following shows a well-formatted PX4 class that follows all style rules: 
class MyClass {
public:

	/**
	 * @brief Description of what this function does.
	 *
	 * @param[in] input_param  Clear description of the input [units]
	 * @return Whatever we are returning [units]
	 */
	float doSomething(const float input_param) const {
		const float in_scope_variable = input_param + kConstantFloat;
		return in_scope_variable * _private_member_variable;
	}

	void setPrivateMember(const float private_member_variable) {
		_private_member_variable = private_member_variable;
	}

	/**
	 * @return Whatever we are "getting" [units]
	 */
	float getPrivateMember() const { return _private_member_variable; }

private:
	static constexpr float kConstantFloat{1.f};
	float _private_member_variable{0.f};
};

​
clang-tidy

In addition to formatting, PX4 runs clang-tidy for static analysis. The project’s .clang-tidy file in the repository root configures which checks are enabled. Common checks enforce:
  • Use of nullptr instead of NULL or 0 for pointers.
  • Avoiding C-style casts in favor of static_cast, reinterpret_cast, etc.
  • Proper use of const and constexpr.
  • Range-based for loops where applicable.
clang-tidy warnings in CI are treated as errors for new code. Do not suppress warnings with // NOLINT unless you have a documented reason, and only for code that genuinely cannot be fixed.

​
Python style

Python files in the repository are checked with mypy for type correctness and flake8 for style. Run both locally if you modify Python tooling: 
python -m mypy path/to/script.py
python -m flake8 path/to/script.py

​
Commit conventions for style changes

Follow the conventional commit format for formatting commits. Use the style type: 
style(ekf2): apply clang-format to new files
Do not include AI-generated attribution in commits. No Co-Authored-By: Claude lines, no “Generated with Claude Code” footers. Commits with AI attribution footers will be rejected during review.

Build docs developers (and LLMs) love

Get started for freeTalk to us