File names should be created with CamelCase (according to the class they contain).

PHP files (files with the php suffix), should not have any whitespaces before or after the opening and closing php tag. The closing tag is preceded by an empty line.

The closing php tag must always be on the last line of the file. The closing php tag is not terminated with a newline character. File encoding is UTF-8. The default permissions for folders are octal 0755, for files octal 0644.? partially Only if the file must be executable (i.e. from console) use octal 0744 for files.

One tab will be used for indentation. So, indentation should look like this:

<?php
// Base level
// Level 1
// Level 2
// Level 1
// Base level
?>

Indentation is always symmetrical. Any opening syntax construct that begins on a new line should be matched with a closing construct (that also begins on a new line) indented at the same level. Any lines enclosed by a beginning and ending construct should be indented exactly one tab in from the enclosing lines. If the contents of an enclosure are broken out over multiple lines, then no enclosed elements should be on the same line as the enclosing structures.

In the control structures there should be 1 (one) space before the first parenthesis and 1 (one) space between the last parenthesis and the opening bracket.

Always use curly brackets in control structures, even if they are not needed. They increase the readability of the code, and they give you fewer logical errors.

Opening curly brackets should be placed on the same line as the control structure. Closing curly brackets should be placed on new lines, and they should have same indentation level as the control structure. The statement included in curly brackets should begin on a new line, and code contained within it should gain a new level of indentation.

Ternary operators (?:) should only be used to set default values for variables or array keys which may be undefined or empty, or for simple true/false comparisons, and must fit on one line of code. if a ternary exceeds these constraints, it should be broken out into a full if block.

Parentheses may be added to the conditional expression or entire ternary statement for clarity.

Variable names should be as descriptive as possible, but also as short as possible. Normal variables should start with a lowercase letter, and should be written in [wiki:CamelBack camelBack] in case of multiple words. Note that even variables containing objects must not start with a capital letter.

Parameters with a default value, should be placed last in function definition. Try to make your functions return something, at least true or false - so it can be determined whether the function call was successful.

The namespace declaration must appear directly after the opening php tag, separated by an empty line. Any static dependencies appear as one block after the namespace declaration, separated by an empty line.

Namespaces: classes should always begin with a namespace definition. This definition should always be preceded by a single newline, and as always, all PHP blocks should begin with a full <?php long tag.

Static dependencies: any basic, unchangeable utility classes which this class depends on or otherwise references should go here. Class references should be fully resolved but must not have a leading backslash (\).

Class definition: this is the only place where classes may be used without being referenced or imported elsewhere (i.e. neither statically nor dynamically). As with static dependencies, the parent class reference should be fully resolved.

Dynamic dependencies: any classes on which this class depends that can be changed through configuration. These may be classes that this class instantiates, or that are used statically. Keys of this array should be the name of the class dependency in camelBack format, and the value should be a fully-namespaced class reference.

Constructor: constructors must always accept exactly one parameter, which must be an array. Only required class bootstrapping code should be put here. This makes classes easier to test. For static classes, this should be replaced with public static function __init(), which takes no parameters. This method is called when the class is first loaded into memory.

Initializer: any additional class bootstrapping code goes here. This method is automatically called by Object::__construct(), which may be disabled by passing 'init' => false to parent::__construct().

A common method grammar and vocabulary should be adhered to as much as possible, and concise, memorable method names should be used in all other cases. Prefixes and suffixes like get* and set* should always be avoided. Method names should always communicate exactly what they do, without containing any redundancies, particularly with respect to the class name, i.e. Dispatcher::dispatch() (wrong). Where possible, method names should also communicate whether the method is a "sub-routine" (performs an action) or a "pure function" (returns a value), for example:

run() (sub-routine)

find() (function)

set() (sub-routine)

value() (function)

If a function has a reciprocal sub-routine (or vice-versa), they should be combined where possible, using an optional parameter to differentiate. The basic pattern is as follows:

Error and Exceptions messages roughly follow the code documenting standard. The following two sections are cited from that standard and especially apply.

All documentation must be written in English and must follow the basic rules of punctuation. Sentences usually end with a period. Sentences are separated by one space from each other. The first letter of a word must be capitalized if it's the beginning of a sentence, following a period or exclamation mark.

Markdown syntax can be used in all docblocks [here: messages, the author]. As a rule of thumb you should wrap in single backticks if you're talking about code. Please note that null, false and true must always be wrapped in single backticks.

As in other places variables which appear in strings where they get expanded must be wrapped in curly braces. Those variables are most often good candidates for also getting wrapped in backticks.

Sometimes a variable within a message may contain no content at all (in the event of an error condition that's possible). In order to still get meaningful messages places where dynamic content is inserted must be preceded by a term describing the type of content to be inserted.

The message must not include the method/class name.

Examples of good exception messages:

"Could not write template `{$template}` to cache."
"Entity `{$entity}` not found."
"Rule `{$rule}` is not a validation rule."
'Could not route request.'

Examples of bad exception messages:

"Could not write template {$template} to cache." // Literal not marked as such.
"Could not write template '{$template}' to cache." // Using ticks instead of backticks.
"`{$entity}` not found." // `$entity` may be empty.