While our source tree is currently in a number of different Coding Styles and the general rule applies to adhere to style of surrounding code when you are making changes, it is our goal to unify the style of our source tree and making it adhere to a single style.
This document describes the preferred style for new source code files and the preferred style to convert existing files to.
This style guide will not apply to 3rd party libraries that are imported verbatim to our code (e.g. NSS, NSPR, SQLite, various media libs, etc.).
Our own managed and maintained code should adhere to this guide where possible or feasible. It departs from the Mozilla Coding Style in some ways, but considering Mozilla has abandoned their code style in favor of Google code style, we are now defining our own preferred style.
**Important**: if you touch a file to make it adhere to this code style, do not mix code changes with formatting changes. Always make formatting changes throughout a file a single, separate commit that does not touch code functionality!
- Maximum line length is 120 characters. This departs from the often-used 80-character limit which is rooted in the archaic use of 80-column text terminals and should no longer apply in this day. Github, our chief web VCS, has no issues dealing with 120 character lines either.
- Variables passed to functions are passed on one line unless the line would exceed the maximum length, in which case variables will be passed 1-per-line, expression-aligned (see "long line wrapping").
- Avoid trailing commas.
- Comment blocks are line-quoted if they appear within functions.
- Comment blocks are block-quoted if they appear outside of functions (e.g. as function definition headers).
## C and C++
Applies to `*.c`, `*.cc`, `*.cpp` and `*.h`. Potentially also `*.mm` for Mac code.
- Place function return types, including modifiers like `static` on the same line as the function signature.
```C++
static bool somefunction(int var1, char* var2) {
...
}
```
- When using templates, do not add spaces between the template name and its object.
```C++
nsCOMPtr<nsISomeInterfaceType>
```
- Use braces, even for single-command lines. Avoid placing executed code on the expression line or using single-line indentation to indicate the scope. Always brace executed code.
- Pointer types: When declaring pointer types, place the `*` with the pointer type. When referencing pointer types, place `*` or `&` with the variable. Do not use `*` by itself with whitespace. Some existing modules still use the `int *myvar1;` style, these should be converted. Until conversion is done, follow existing, surrounding code style or convert it when you touch a file.
If statements on a single line become overly long, they should be split into multiple lines:
- Binary operators (including ternary) must be left on their original lines if the line break happens around the operator. The second line should start in the same column as the start of the expression in the first line.
- Lists of variables (e.g. when calling or declaring a function) should be split so variables are listed one-per-line, where second and subsequent lines start in the same column as the first variable listed, even if more than one variable would fit on the line segment until the wrapping column.
