Source Code Management
Branching Model
The PX4 project uses a three-branch Git branching model:
master is by default unstable and sees rapid development.
beta has been thoroughly tested. It's intended for flight testers.
stable points to the last release.
We try to retain a linear history through rebases and avoid the Github flow. However, due to the global team and fast moving development we might resort to merges at times.
To contribute new functionality, sign up for Github, then fork the repository, create a new branch, add your changes, and finally send a pull request. Changes will be merged when they pass our continuous integration tests.
All code contributions have to be under the permissive BSD 3-clause license and all code must not impose any further constraints on the use.
Code Style Formatting
PX4 uses astyle for code formatting. Valid versions are
astyle 2.06 (deprecated)
astyle 3.01 (recommended)
Once installed, formatting can be checked with ./Tools/astyle/check_code_style_all.sh
. The output should be Format checks passed
on a clean master. If that worked, make format
can be used in the future to check and format all files automatically.
File name conventions
Going forward we aim to follow these file naming conventions:
C++ source files should be named in CamelCase and match the class name. E.g. A C++ file containing a class named
FooThing
should be namedFooThing.cpp
.C++ header files should be named the same as source files except have the suffix
.hpp
.C++ header files that are required to be C compatible, should have the suffix
.h
.Folder names are
snake_case
for the first level insidemodules
/drivers
/systemcmds
/etc. but should be named CamelCase when more deeply nested to match the source and header files.Test files must have a
Test
suffix as shown:FooThingTest.cpp
.One exception to the rules above are the MAVLink streams in src/modules/mavlink/streams which are ALL_UPPERCASE.hpp matching the MAVLink message name.
In-Source Documentation
PX4 developers are encouraged to create appropriate in-source documentation.
Source-code documentation standards are not enforced, and the code is currently inconsistently documented. We'd like to do better!
Currently we have two types of source-based documentation:
PRINT_MODULE_*
methods are used for both module run time usage instructions and for the Modules & Commands Reference in this guide.The API is documented in the source code here.
Good examples of usage include the Application/Module Template and the files linked from the modules reference.
We encourage other in-source documentation where it adds value/is not redundant.
Developers should name C++ entities (classes, functions, variables etc.) such that their purpose can be inferred - reducing the need for explicit documentation.
Do not add documentation that can trivially be assumed from C++ entity names.
Commonly you may want to add information about corner cases and error handling.
Doxgyen tags should be used if documentation is needed:
@class
,@file
,@param
,@return
,@brief
,@var
,@see
,@note
. A good example of usage is src/modules/events/send_event.h.
Commits and Commit Messages
Please use descriptive, multi-paragraph commit messages for all non-trivial changes. Structure them well so they make sense in the one-line summary but also provide full detail.
Use git commit -s
to sign off on all of your commits. This will add signed-off-by:
with your name and email as the last line.
This commit guide is based on best practices for the Linux Kernel and other projects maintained by Linus Torvalds.
Last updated