Style Considerations
The two golden rules (especially the one about making the code more readable) apply very strongly here. If you have a strong opinion (and a good reason) to act differently than these conventions suggest, go for it. The goal here, however, is to remind us of our objectives with our code. We want it readable, we want it easy to maintain, and we want it consistent.
Indentation
There are two rules which tend to be particularly divisive, and which tend to cause especially distasterous disasters when not heeded.
- Indent your code with tab (\t) characters.
If you use tabs to indent, everybody is happy with the spacing we want; there is no editor that cannot handle tabs, nor is there a language we will write in that likewise does not support them. In python, use what the file already includes (python is not happy if we mix tab/space indentation).
- Do not change the indentation style of an existing file.
Even if you believe it is wrong, use the indentation style that will keep the entire file consistent. If you do change the indentation style of a file, change it throughout the file and make no other changes (otherwise this will obscure our version control). For indentation-sensitive languages, this means checking for syntax and runtime errors.
Braces
- Braces, when they are used, should always be placed on their own line, such that open- and close-braces match vertically.
The motivation here is that matching braces are most productive for visually identifying blocks of code. Putting open-braces on the line of the statement retards this benefit.
Example: Bad
int main() { ... return 0; }
Example: Good
int main() { ... return 0; }
