A general guideline is to keep the formatting as similar to the rest of the project as possible. It might be a good idea to write a general guideline that all developers abide to.
Here's how the Angband source code is styled:
PHP Code:
written by Robert Ruehlmann, Ben Harrison, and Gwidon S. Naskrent
There are lots of things that are commonly considered good style for Angband code. The Vanilla Angband source code is the general guideline.
Here are some of the "rules":
* Don't use floating point calculations.
* Don't break savefile compatibility (if not absolutely necessary).
* No C++ code. That also means no '//' comments.
* Put system dependent code between #ifdef xyz ... #endif /* xyz */ .
* No "magic numbers". Use #defines. The #defines should be in defines.h rather than the source file, unless they're very local (such as dungeon generation parameters).
And some code-style guidelines:
* Comments, comments, comments. Multi-line comments should look like:
/*
* A multi-line
* comment.
*/
instead of:
/* A multi-line
* comment */
* Indentation with tabs. But generally avoid getting lines over 80 characters.
* Put curly braces ('{', '}') on an extra line with the same indentation level as the previous line. Example:
if (value == 0)
{
do_something();
}
* Put empty lines between code-blocks. Example:
/* Do something */
do_something();
/* Do something else */
do_something_else();
* Spaces around the mathematical, comparison, and assignment operators ('+', '-', '*', '/', '=', '!=', '==', '>', ...).
* Spaces between C-identifiers like 'if', 'while', 'for', and 'return' and the opening brackets ('if (foo)', 'while (bar)', ...).
* No spaces between function names and brackets and between brackets and function arguments (function(1, 2) instead of function ( 1, 2 )).
* If the precedence of operations is ambiguous then put brackets around them. Also try to insert parentheses whenever necessary for readability, eg. around (foo & RF3_SOME_DEFINE). There is usually no ambiguity and no macro resolution, but this is an aesthetic detail.
* If a function takes no arguments then it should be declared with a void argument list. Example: int foo(void) instead of int foo().
* Function declaration and definition should look the same.
* Don't assume that functions declared without a return type return int. Specify the type explicitly. Example: int foo(void) instead of foo(void).