General:
– code as if whoever maintains your code is a violent psychopath who knows where you live
– code in paragraphs, i.e. group related chunks and separate them by a new line
– indent style uses the K & R style
– columns 100 max, unless workaround (i.e. HTML) is needed
– The use of <?php ?> to delimit PHP code is encouraged, especially for core packages
– Using <? ?> is OK for main PHP files
File Format:
– use the UNIX file format, that is a LF character for end of lines
– make sure there is no whitespace after the last non whitespace character for every line
Comments:
– avoid // for comments in PHP
– comments should start with #
– /* */ style in PHP is OK for multiple lines
– when commenting out code lines add the comment character at the start of the line,
makes it easier to separate form normal comments,
Tabs:
– tab indent size should be set to 4
– tabs should be used for identing only NOT for alignment
– a tab character can only be used at the start of the before any non-whitespace character
– checkout the Smart Tabs vim plugin
function do_something() {
<TAB>$long_variable = foo($baz);
<TAB>$short = foo($bar);
^^^^^^^^^
space
}
Identifiers:
– abbreviations should be avoided, ie $session->initialise() not $session->init()
– common abbreviations are acceptable as long as they are used the same way throughout the project.
Vars:
– hungarian notation is to be avoided for scripting languages
– use all lower case letters separated with underscores, i.e. $first_name
– space on each sides of equal for assignment, i.e. $first_name = ‘John’;
Hashes & Associative Arrays:
– in Perl both $hash{key} and $hash{‘key’} are OK
– in PHP both $array[key] and $array[‘key’] are OK
Constants:
– all uppercase separated by underscores, eg SESSION_TIMEOUT
– in Perl use Readonly instead of constant
– for PHP constants related to a class, prefix with the name of the class they are used in.
for example, the constants used by the Benon_DB package should all begin with “Benon_DB_”.
Strings:
– avoid using double quotes unless necessary
– only simple variables are allowed in an interpolated string
– do not use hashes, arrays, ${var} expressions in interpolated strings
$var = ‘My String’;
$associative_array[‘key’];
$var = “…string… $some_var …more…’.$another_var.’_more stuff…’;
$var = “…string…’.$another_var.’_more stuff…’;
$sql = ‘INSERT INTO mytable (field) VALUES (‘.$db->quote($var).’)’;
$var = “My String\n”;
Control:
– one space on each side of the brackets
for ($i; $i < 10; $i++) {
# …
}
foreach ($arr as $k => $v) {
# …
}
while ($i < 10) {
# …
}
Tests:
– one space on each side of the brackets
– uncuddled elses: return line after a closing curly bracket
– only “if (…) do_something” in ONE line are allowed
if ($a == $b) {
# …
}
elsif ($a == 1) {
# …
}
else {
# …
}
Functions:
– use all lower case words separated by and underscore
– follow the verb/subject rule, ie get_this, do_something, is_ready
– use a space between the function/sub keyword and the identifier
– use arrays as arguments for public functions in core packages
– use PHPdoc http://manual.phpdoc.org
function print_name($first, $last) {
echo $var;
}
foo(‘John’, ‘Doe’);
foo(array(first => ‘John’, two => ‘Doe’));
foo(array(
first => ‘John’,
two => ‘Doe’
));
Classes:
– use CamelCase, i.e. SomeNamespace::SomePackage
– In PHP use an underscore to fake namespace separation, i.e. SomeNamespace_SomePackage
Hopefully one day PHP devs will get a clue and support namespaces 🙂
– For PHP constructors, use __construct not the name of the package
– abreviations are left uppercase, ie “DB” not “Db”, i.e. Benon_DB_Result
SQL:
– keywords all uppercase, ie SELECT FROM blah WHERE name = ‘Joe’;
