For significant changes, consider starting a discussion on the Cantera
Users' Group to plan your modifications so that they can be implemented
efficiently and in a way that doesn't conflict with any other planned
Fork the Cantera/cantera repository on Github
Clone your new repository or add it as a remote to an existing repository
Check out the existing master branch, then start a new feature branch for
When making changes, write code that is consistent with the surrounding code
(see the style guidelines below)
Add tests for any new features that you are implementing to either the
GoogleTest-based test suite or the Python test suite.
Add examples that highlight new capabilities, or update existing
examples to make use of new features.
As you make changes, commit them to your feature branch
Configure Git with your name and e-mail address before making any commits
Use descriptive commit messages (summary line of no more than 72 characters,
followed by a blank line and a more detailed summary, if any)
Make related changes in a single commit, and unrelated changes in separate
Make sure that your commits do not include any undesired files, e.g., files
produced as part of the build process or other temporary files.
Cantera is licensed under a BSD
allows others to freely modify the code, and if your Pull Request is accepted,
then that code will be release under this license as well. The copyright for
Cantera is held collectively by the contributors. If you have made a
significant contribution, please add your name to the AUTHORS file.
Try to follow the style of surrounding code, and use variable names that
follow existing patterns. Pay attention to indentation and spacing.
Configure your editor to use 4 spaces per indentation level, and never to
Avoid introducing trailing whitespace
Limit line lengths to 80 characters when possible
Write comments to explain non-obvious operations
All classes, member variables, and methods should have Doxygen-style comments
(e.g., comment lines starting with //! or comment blocks starting with /*!)
Avoid defining non-trivial functions in header files
Header files should include an 'include guard'
Protected and private member variable names are generally prefixed with
m_. For most classes, member variables should not be public.
Class names use InitialCapsNames
Methods use camelCaseNames
Do not indent the contents of namespaces
Code may make use of most C++11 features, with the exceptions of delegating
constructors, inheriting constructors, and non-static data member
initializers. These limitations are needed to keep the minimum required
compiler versions at GCC 4.6, Clang 3.1, Visual Studio 2013 and Intel 14.0.
Avoid manual memory management (i.e. new and delete), preferring to use
standard library containers, as well as std::unique_ptr and
std::shared_ptr when dynamic allocation is required.
Portions of Boost which are "header only" may be used. If possible, include
Boost header files only within .cpp files rather than other header files to
avoid unnecessary increases in compilation time. Boost should not be added
to the public interface unless its existence and use is optional. This keeps
the number of dependencies low for users of Cantera. In these cases,
CANTERA_API_NO_BOOST should be used to conditionally remove Boost dependencies.
While Cantera does not specifically follow these rules, the following style
guides are useful references for possible style choices and the rationales behind them.