VéloFille

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’;