Coding Standards

These standards for code formatting and documentation should be followed by anyone contributing to Radical PHP. Currently these standards are a work in progress and not all code is following them as we are still RFCing and working out what we like. The ones in this list howeaver are finalized.

File Formatting

Closing PHP Tag

Files containing only PHP code should always omit the closing PHP tag (?>). It is unnneccesary and it prevents many of the elusive white screens of death. For other files it is up to the maintainer of the code unless otherwise noted.

Indentation

All code indentation should be done using tabs, NOT spaces (editors should equate a tab to 4 spaces). But aligning comments after the statements should be done using spaces, NOT tabs.

// indented 1 tabs
$it_var       = 'word';       // indented with tabs and aligned value & comments
$count  = strlen($it_var);    // with those above/below using spaces

Line Endings

Line endings should be a windows style \r\n.

File Naming

• All class names must be in cammel case.
• All interfaces must start with a capital I
• All extensions for library files must be .php (lowercase)

Encoding

All PHP files must be encoded with the UTF-8 encoding. All files must not include a BOM without exception.

Programming Conventions

Namespaces

The namespace definition must be in statement form, block form is not allowed under any circumstances.

All application database models must be located in \PROJECT\DB where PROJECT is the Projects namespace (as defined by the $_PROJECT variable.

Class Adapters

Classes must not use underscores to show heighrarcy, namespaces must be used instead. For example:

<?php
namespace Web;
class Session_Storage_Database extends ModuleBase implements ISessionStorage {

Is not the correct way to show an adapter heighrarcy. The correct way is the class Database in the sub namespaces of Session and Storage as seen below.

<?php
namespace Web\Session\Storage;
class Database extends ModuleBase implements ISessionStorage {

Variables

Variable names should be short and concise and contain only lower case letters and underscores. They should be descriptive of how you intend to use them or what data they will be storing. Single letter variables are not acceptable except in the form of loop iterators and similar uses.

<?php
$u = new User();          //Bad, Bad, Bad. Not descriptive at all.
$usr = new User();        //Better but still not right
$user = new User();       //Correct!
$userModel = new User();  //Camel case, not allowed
$user_model = new User(); //Too much infomation

Variable assigments should only be one per line (for statements are an exception to this rule)

$a = 2;
$b = 1;

//NOT 
$a = 2; $b =1;

Constants

Constants should be all upper case and underscores. Global constants should NEVER be used in autoloaded class files, class constants should be used instead. Examples of valid constants include FETCH_ASSOC, MY_TEMPLATE_DIR and IS_DEBUG.

Constants can also be used to emulate enum support. A good example of this is:

abstract class Fetch {
	const ASSOC = 1;
	const NUM = 2;
	const FIRST = 3;
	const ALL_ASSOC = 4;
	const ALL_NUM = 5;
	const ALL_SINGLE = 6;
}

Keywords

Languge keywords such as true, false and null should always be lowercase, the same goes for other reserved keywords such as if, for and array.

Control Structures

We have no oppinion on how you should use brackets in control structures, as long as the code is clean and easy to understand we have no problems with your personal preference. That said howeaver we do not allow the use of endif and similar syntaxes and the bracketed case syntax.