How to successfully make changes to Ninja

We‘re very wary of changes that increase the complexity of Ninja (in particular, new build file syntax or command-line flags) or increase the maintenance burden of Ninja. Ninja is already successfully used by hundreds of developers for large projects and it already achieves (most of) the goals we set out for it to do. It’s probably best to discuss new feature ideas on the mailing list or in an issue before creating a PR.

Coding guidelines

Generally it's the Google C++ Style Guide with a few additions:

  • We have used using namespace std; a lot in the past. For new contributions, please try to avoid relying on it and instead whenever possible use std::. However, please do not change existing code simply to add std:: unless your contribution already needs to change that line of code anyway.
  • Use /// for Doxygen (use \a to refer to arguments).
  • It‘s not necessary to document each argument, especially when they’re relatively self-evident (e.g. in CanonicalizePath(string* path, string* err), the arguments are hopefully obvious).

If you're unsure about code formatting, please use clang-format. However, please do not format code that is not otherwise part of your contribution.