message: Add note to CONTRIBUTING guidelines about avoiding STL use
diff: If you're making a tiny bugfix that only changes a few lines, then you don't really have to worry about how you structure your development or organise branches. You can just make your fix, open up a pull request, and everything can be handled from there on the fly.
  -When making a larger change though, there are more things to take into consideration. Your changes need to be compatible with the project on a larger scale, as well as making sure your development process can merge into the mainline development with other contributors and the project maintainer.
  +# Coding style
  +
  +The coding style is primarily enforced by clang-format for things that can be easily checked by an automatic program. That includes brace style, indentation, spacing, etc.
  +
  +For things that clang-format can't cover, there are a few guidelines below but the golden rule is to try and match the surrounding code as much as possible. The code isn't perfectly consistent so you might see varying naming conventions, avoid adding code that is significantly different to the context.
  +
  +* `auto` is only allowed for types that are prohibitive: STL iterators and lambdas. Everywhere else you should use the explicit type.
  +* Limit STL use to a minimum. Allowed uses are `std::map`, `std::function`, `std::set`, algorithms like `std::sort` and `std::lower_bound`, and type-traits type checks like `std::is_same`. Use `rdcarray` instead of `std::vector` and `rdcstr` instead of `std::string`.
  +* Don't use hungarian notation aside from `m_` for members. Some existing names will use `p` prefixes for pointers but it should be phased out in new code. The exception is when working with hooked functions where the official parameter names have hungarian notation.
  +
  +# Planning larger changes
  +
  +When making a larger change, there are more things to take into consideration. Your changes need to be compatible with the project on a larger scale, as well as making sure your development process can merge into the mainline development with other contributors and the project maintainer.
  There are a few guidelines to follow to make sure that everyone can work together with as little friction as possible:
  