Use CSS for style formating. Like elements color, backgrounds, font size and style and etc.
tag for layout elements on the page.
PHP Coding Standards
!!! This is not a final version. There will be changes and additions. Keep checking back !!!
In order to produce highly consistent source code, we ask that everyone follow the coding standards as closely as possible.
Indentation, Line length and Comments
It is generally recommended that you use 4 spaces for each level of indentation (if you use tabs, make sure that the tab is set to use the equivalent of 4 spaces). The purpose of this is for consistency across editors and operating systems. In some editors it is also possible to change its preferences/settings to use spaces instead of tabs and tell it the amount of spaces to use when indenting.
<?php
$text = 'this is a long text block that is wrapped. Normally, we aim for '
. 'wrapping at 80 chars. Vertical alignment is very important for '
. 'code readability. Remember that all indentation is done with tabs,'
. 'but vertical alignment should be completed with spaces, after '
. 'indenting with tabs.';
?>
When doing non-documentation comments, they should be written using the C style comments (/* */) and standard C++ comments (//).
/*
This is a block comment
It can span multiple lines.
This is the third line.
*/
// And this is a single line comment
The use of the Shell/Perl style comments (#) is discouraged.
String Concatenation
Don't put spaces around the concatenation operator.
<?php
// Correct:
$str = 'one'.$var.'two';
// Not correct:
$str = 'one'. $var .'two';
$str = 'one' . $var . 'two';
?>
Single Line Statements
Single-line IF statements should only be used when using return or continue:
<?php
if ($foo == $bar)
return $foo; // This is acceptable
if ($foo == $bar)
continue; // Allow acceptable
if ($baz == $bun)
$baz = $bar+2; // This is NOT
?>
Comparison Operators
Please use OR and AND for comparison:
<?php
if (($foo AND $bar) OR ($b AND $c)) {
// Correct
}
if (($foo && $bar) || ($b && $c)) {
// NOT correct
}
?>
Ternaries
All ternary operations should follow a standard format:
<?php
$foo = ($bar == $foo) ? $foo : $bar;
?>
All comparisons must be done inside of a parentheses group
<?php
$foo = ($bar > 5) ? ($bar + $foo) : $bar;
?>
When using a ternary return value, you must group the entire ternary in it's own group of parentheses:
<?php
return (($foo != 5) ? $bar : $foo);
?>
Type Casting
Type casting should be done with spaces on each side of the cast:
<?php
$foo = (string) $bar; // Correct
$foo = (string)$bar; // NOT correct
?>
When possible, please use type casting instead of ternary operations:
<?php
// Don't do this:
$foo = ($bar == TRUE) ? TRUE : FALSE;
// Do this:
$foo = (bool) $bar;
?>
Naming Conventions
Having consistent naming conventions throughout your code is good practice.
Framework
Files that are called from a view should be named as "tpl_filename"
tpl_adminpage
Views that are called from a controller should be named as "v_filename"
v_adminview
NO subfolders should be created unless approved by Eric, Anton, or Jason.
Variables
Next are variable names. Variable names are also written in CamelCase, however, the first letter is now lowercase.
This is true for function parameters, too.
Don`t use c-style like $this_is_my_cool_c_style_var.
<?php
// Correct:
$myVariable = 'something';
// Correct:
$fuoBarVariable = 'something';
// Not correct:
$myvariable = 'something';
// Not correct:
$my_variable = 'something';
// Not correct:
$MyVariable = 'something';
?>
Constants
While constants are all uppercase with an underscore used to separate words.
<?php
// Correct:
define('MY_CONSTANT', 'my_value');
$a = TRUE;
$b = NULL;
// Not correct:
define('MyConstant', 'my_value');
$a = True;
$b = null;
?>
Classes
Classes should be descriptive and as best as possible abbreviations should not be used. Use CamelCase (each word is capitalized).
UsersList
SomeUselessClass
Class members
Same as for just variables.
class SomeClass() {
public $userName; // Correct
public $UserName; // NOT correct
private $money_amount; // NOT correct
.....
}
Files
File names should be descriptive and as best as possible abbreviations should not be used.
Use lower case with each word separated by an underscore. Except names of Controllers
file_name.php
user_payments.php
config.php
Controllers
Use name depends URL we need to have. Don`t use underscore for URLs - only if it really need for some reason.
/application/controllers/login.php
/application/controllers/userslist.php
/application/controllers/subscriptions.php
Viewes
Should match name of controller pluse v_ prefix. Like: v_user.php
If view file used in other views, like "footer" or "header" - use tpl_ prefix.
/application/views/v_login.php
/application/views/v_userslist.php
/application/views/v_subscriptions.php
/application/views/tpl_header.php
/application/views/tpl_user_table.php
Model
If it will use only in one controller - name of model should match name controller with m_ prefix. Like: m_user.php
If model will be used in several controllers - you need to name it as entity that it presenting.
Like:
/application/controllers/userlist.php
/application/controllers/userinfo.php
/application/models/m_user.php
Regular Expressions
When coding regular expressions please use PCRE rather than the POSIX flavor. PCRE is considered more powerful and faster.
<?php
// Do this:
if (preg_match('/abc/i'), $str) {}
// Don't do this:
if (eregi('abc', $str)) {}
?>
Use single quotes around your regular expressions rather than double quotes. Single-quoted strings are more convenient because of their simplicity. Unlike double-quoted strings they don't support variable interpolation nor integrated backslash sequences like \n or \t, etc.
<?php
// Do this:
preg_match('/abc/', $str);
// Don't do this:
preg_match("/abc/", $str);
?>
When performing a regular expression search and replace, please use the $n notation for backreferences. This is preferred over \\n.
<?php
// Do this:
preg_replace('/(\d+) dollar/', '$1 euro', $str);
// Don't do this:
preg_replace('/(\d+) dollar/', '\\1 euro', $str);
?>
Finally, please note that the $ character for matching the position at the end of the line allows for a following newline character. Use the D modifier to fix this if needed. More info: http://blog.php-security.org/archives/76-Holes-in-most-preg_match-filters.html.
<?php
$str = "email@example.com\n";
preg_match('/^.+@.+$/', $str); // TRUE
preg_match('/^.+@.+$/D', $str); // FALSE
?>
Control Structures
As you know control structures include if, while, foreach statements, etc. For structures like these, opening curly brace are kept on the same line as the declaration and the closing curly brace is aligned at the same indent level as the start of the control structure. Also there is usually one space between the control keyword and opening parenthesis and also one space between the closing parenthesis and the opening curly brace.
if (condition) {
// code...
} else {
// more code...
}
while (condition) {
// code...
}
Functions
For functions, the opening curly brace are kept on the same line as the declaration and the closing curly brace is aligned at the same indent level as the start of the function. There is also no space between the opening parenthesis and the function name. Also if the function is a method for a Class it is advised that you state the scope of the function (ie. public, private or protected).
public function myFunction($arg1, $arg='') {
//code...
}
Note that arguments that are optional should be placed after those that are required.
PHP Tags
Then there is the matter of whether to use short tags delimit your PHP code. It is recommended that you do it the regular way, as it is the most portable way and ensures that your code will run on any operating system and server setup.
<?php //code... ?>
But feel free to use shot form of tag in HTML for printing someting, like
Documentation
Documenting your code is also important. When all is said and done you want to be able to look back at your code and immediately know what the purpose of a particular Class or function is. Here is an example:
/**
* Short description of what the class does
*
* @category CategoryName
* @package PackageName
* @author Original Author <author@example.com>
* @version Release: @package_version@
*/
class FooBarBaz {
/**
* The status of foo's universe
*
* @var string
*/
public $foo = 'unknown';
/**
* Short description of what function does
*
* @param string $arg1 the string to quote
* @param int $arg2 an integer of how many problems happened.
* @return int the integer of the set mode used. FALSE if foo
* foo could not be set.
*/
public function fooBar($arg1, $arg2='') {
// code...
return 1;
}
}
Documentation
Documenting your code is also important. When all is said and done you want to be able to look back at your code and immediately know what the purpose of a particular Class or function is. Here is an example:
/**
* Short description of what the class does
*
* @category CategoryName
* @package PackageName
* @author Original Author <author@example.com>
* @version Release: @package_version@
*/
class FooBarBaz {
/**
* The status of foo's universe
*
* @var string
*/
public $foo = 'unknown';
/**
* Short description of what function does
*
* @param string $arg1 the string to quote
* @param int $arg2 an integer of how many problems happened.
* @return int the integer of the set mode used. FALSE if foo
* foo could not be set.
*/
public function fooBar($arg1, $arg2='') {
// code...
return 1;
}
}
SQL
Use uppercase for all SQL expression.
Correct:
$sql = "SELECT f1, f2, f3 FROM some_table WHERE id = ? AND status = ? AND author = ?";
$this->db->query($sql, array(3, 'live', 'Rick'));
Not correct:
$sql = "select f1, f2, f3 from some_table where id = ? and status = ? and author = ?";
$this->db->query($sql, array(3, 'live', 'Rick'));
