1# How to successfully make changes to Ninja 2 3We're very wary of changes that increase the complexity of Ninja (in particular, 4new build file syntax or command-line flags) or increase the maintenance burden 5of Ninja. Ninja is already successfully used by hundreds of developers for large 6projects and it already achieves (most of) the goals we set out for it to do. 7It's probably best to discuss new feature ideas on the 8[mailing list](https://groups.google.com/forum/#!forum/ninja-build) or in an 9issue before creating a PR. 10 11## Coding guidelines 12 13Generally it's the 14[Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) with 15a few additions: 16 17* We have used `using namespace std;` a lot in the past. For new contributions, 18 please try to avoid relying on it and instead whenever possible use `std::`. 19 However, please do not change existing code simply to add `std::` unless your 20 contribution already needs to change that line of code anyway. 21* Use `///` for [Doxygen](http://www.doxygen.nl/) (use `\a` to refer to 22 arguments). 23* It's not necessary to document each argument, especially when they're 24 relatively self-evident (e.g. in 25 `CanonicalizePath(string* path, string* err)`, the arguments are hopefully 26 obvious). 27 28If you're unsure about code formatting, please use 29[clang-format](https://clang.llvm.org/docs/ClangFormat.html). However, please do 30not format code that is not otherwise part of your contribution. 31