Platform-specific code should use the predominant coding convention for that platform. DirectShow code should look familiar to a Windows coder, QuickTime code should look familiar to an Apple coder, and so on. Otherwise, we follow the conventions described here.
For VP8, our whitespace rules are defined by the following astyle transform:
astyle --style=bsd --min-conditional-indent=0 --break-blocks \
--pad-oper --pad-header --unpad-paren \
--align-pointer=name --indent-preprocessor \
--indent-labels "$@"This boils down to:
+, - , * , / , if, while, etc.)Conventions for VP9 differ from legacy VP8 conventions, and are generally consistent with the Google C++ Style Guide and cpplint. Exceptions are function naming and maximum visual clarity of table data. With regard to local styles, let Parting Words (below) be your guide.
For historical reasons, the code is not always consistent with these
conventions. These inconsistencies should be resolved, not propagated. i.e.,
if you find something that's named inconsistently, submit a patch fixing it.
Some identifiers conform to these conventions but are spelled funny (e.g.
de_quantize) as a result of some automatic transforms. You can submit
patches fixing these as well.
Use common sense and be consistent.
If you are editing code, take a few minutes to look at the code around you and determine its style. If it uses spaces around if clauses, you should, too. If comments have little boxes of stars around them, make your comments have little boxes of stars around them too.
The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you are saying, rather than on how you are saying it. We present style rules here so people know the vocabulary, but local style is also important. If code you add to a file looks drastically different from the existing code around it, the discontinuity throws readers out of their rhythm when they go to read it. Try to avoid this.