Coding Guidelines

Test before code!

When contributing a new feature or revising an existing one, writing the test comes first. You're not done until all tests pass. If your new code or change does not have a test or three, it will be reverted.

Submitting code to the repository

Only tested, highly quality code is allowed to be checked in. Developers who break a build is going to be made fun of, and if it continues we might have to look at commit privileges.

• Before committing, update trunk just prior to your planned check in, and merge your code properly.
• Test your feature for functional issues
• Run scripts/runalltests.php
• Check that no other changes to trunk or your branch have been made so your merge will succeed

If your testing and runalltests.php succeeds, you are free to check your code in.

PHP Doc Comments

All classes and methods must have finished PHP Doc comments, suitable for processing by PhpDocumenter. The gnarlier the code, the better the explanation.

Code should be literate, that is that to a very average PHP coder (and there's a lot of them), the code is self explanatory without comments.

Constants, particularly magic values, must be commented.

Global variables

Only $db and $kernel are allowed as global variables. Creating or accessing any other global variable is prohibited.

Super globals

Access to $_GET, $_POST, $_REQUEST, $_COOKIE, $_SESSION, and $_SERVER is highly problematic. Unless you are a kernel class developer, your code should not touch any super global.

Global Functions

Unless a global function is to be used by all modules, it shall be in a class.

Encoding

UTF-8 Encoding. All text files (PHP, CSS, HTML, etc) must be edited with editors that are aware of UTF-8, and saved in that format if possible.
Unix line endings are mandatory

Formatting

All code should be formatted to the XMB 2.0 style. This is easily achieved using the following PHPEclipse style helper.

Bracing

Braces are not optional, even for one line flow control.