Manual:Coding conventions/PHP

This page describes the coding conventions used within files of the MediaWiki codebase written in PHP. See also the general conventions that apply to all program languages, including PHP. If you would like a short checklist to help you review your commits, try using the pre-commit checklist.

To help developers fix code with an inadequately spacey style, a tool called stylize.php has been created, which uses PHP's tokenizer extension to add spaces at the relevant places. It's recommended to run this over new files committed to SVN, but not so much for fixing current files.

Assignment expressions
Using assignment as an expression is surprising to the reader and looks like an error. Do not write code like this:

Space is cheap, and you're a fast typist, so instead use:

Using assignment in a clause used to be legitimate, for iteration:

This is unnecessary in new code; instead use:

Spaces
MediaWiki favors a heavily-spaced style for optimum readability.

Put spaces on either side of binary operators, for example:

Put spaces next to parentheses on the inside, except where the parentheses are empty. Do not put a space following a function name.

Opinions differ as to whether control structures, , , etc. should be followed by a space; the following two styles are acceptable:

In comments there should be one space between the or  character and the comment, and a comment should be put on its own line.

To help developers fix code with an inadequately spacey style, a tool called [//svn.wikimedia.org/svnroot/mediawiki/trunk/tools/code-utils/stylize.php stylize.php] has been created, which uses PHP's tokenizer extension to enforce most whitespace conventions automatically.

Ternary operator
The can be used profitably if the expressions are very short and obvious:

But if you're considering a multi-line expression with a ternary operator, please consider using an block instead. Remember, disk space is cheap, code readability is everything, "if" is English and  is not.

5.3 shorthand
Since we still support PHP 5.2.x, use of the shorthand ternary operator introduced in PHP 5.3 is not allowed.

String literals
For simple string literals, single quotes are slightly faster for PHP to parse than double quotes. Perhaps more importantly, they are easier to type, since you don't have to press shift. For these reasons, single quotes are preferred in cases where they are equivalent to double quotes.

However, do not be afraid of using PHP's double-quoted string interpolation feature: This has slightly better performance characteristics than the equivalent using the concatenation (dot) operator, and it looks nicer too.

Heredoc-style strings are sometimes useful:

Some authors like to use END as the ending token, which is also the name of a PHP function. This leads to IRC conversations like the following:

	vim also has ridiculously good syntax highlighting. 	it breaks when you write <<	TimStarling, but if you write <<	I have to keep changing it to ENDS so it looks like a string again 	fix the bug in vim then! 	brion-codereview: have you ever edited a vim syntax script file? 	hehehe 	http://tstarling.com/stuff/php.vim 	that's half of it... 	here's the other half: http://tstarling.com/stuff/php-syntax.vim 	1300 lines of sparsely-commented code in a vim-specific language 	which turns out to depend for its operation on all kinds of subtle inter-pass effects TimStarling: it looks like some franken-basic language.

Functions and parameters
Avoid passing huge numbers of parameters to functions or constructors:

It quickly becomes impossible to remember the order of parameters, and you will inevitably end up having to hardcode all the defaults in callers just to customise a parameter at the end of the list. If you are tempted to code a function like this, consider passing an associative array of named parameters instead.

In general, using boolean parameters is discouraged in functions. In, without looking up the documentation for , it is impossible to know what those parameters are meant to indicate. Much better is to either use class constants, and make a generic flag parameter:



Or to make your function accept an array of named parameters:



Try not to repurpose variables over the course of a function, and avoid modifying the parameters passed to a function (unless they're passed by reference and that's the whole point of the function, obviously).

C borrowings
The PHP language was designed by people who love C and wanted to bring souvenirs from that language into PHP. But PHP has some important differences from C.

In C, constants are implemented as preprocessor macros and are fast. In PHP, they are implemented by doing a runtime hashtable lookup for the constant name, and are slower than just using a string literal. In most places where you would use an enum or enum-like set of macros in C, you can use string literals in PHP.

PHP has three special literals:, and. Homesick C developers write as  because they want to believe that it is a macro defined as. This is not necessary.

Use not. They have subtly different meanings:

And the latter has poorer performance.

Naming
Use lowerCamelCase when naming functions or variables. For example:  Use UpperCamelCase when naming classes:. Use uppercase with underscores for global and class constants:,. Other variables are usually lowercase or lowerCamelCase; avoid using underscores in variable names.

There are also some prefixes used in different places:

Functions

 * (wiki functions) – top-level functions, e.g.

Verb phrases are preferred: use instead of.

Variables

 * – global variables, e.g., . Always use this for new globals, so that it's easy to spot missing "" declarations. In extensions, the extension name should be used as a namespace delimiter. For example, , not.

It is common to work with an instance of the  class; we have a naming convention for these which helps keep track of the nature of the server to which we are connected. This is of particular importance in replicated environments, such as Wikimedia and other large wikis; in development environments there is usually no difference between the two types, which can conceal subtle errors.


 * – a  object for writing (a master connection)
 * – a  object for non-concurrency-sensitive reading (this may be a read-only slave, slightly behind master state, so don't ever try to write to the database with it, or get an "authoritative" answer to important queries like permissions and block status)

The following may be seen in old code but are discouraged in new code:


 * – Session variables, e.g.
 * – Cookie variables, e.g.
 * – Post variables (submitted via form fields), e.g.
 * – object member variables: . This is discouraged in new code, but try to stay consistent within a class.

Pitfalls

 * Understand and read the documentation for  and  . Use them only when appropriate.
 * is inverted conversion to boolean with error suppression. Only use it when you really want to suppress errors. Otherwise just use . Do not use it to test if an array is empty, unless you simultaneously want to check if the variable is unset.
 * Do not use to test for .  Using  in this situation could introduce errors by hiding mis-spelled variable names. Instead, use
 * Study the rules for conversion to boolean. Be careful when converting strings to boolean.
 * Be careful with double-equals comparison operators. Triple-equals is often more intuitive.
 * is true
 * is true
 * is false
 * To check if two scalars that are supposed to be numeric are equal, use "==", e.g. (5 == "5") is true.
 * To check if two variables are both of type 'string' and are the same sequence of characters, use "===", e.g. ("1.e6" === "1.0e6") is false.
 * To check if two scalars that should be treated as strings are equal as strings, use strcmp, e.g. strcmp(13,"13") is 0.
 * Array plus does not renumber the keys of numerically-indexed arrays, so . If you want keys to be renumbered, use array_merge:
 * Make sure you have  set to  for PHP 5. This will notify you of undefined variables and other subtle gotchas that stock PHP will ignore. See also Manual:How to debug.
 * When working in a pure PHP environment, remove any trailing  tags. These tags often cause issues with trailing white-space and "headers already sent" error messages (cf. 17642 and http://news.php.net/php.general/280796).
 * Do not use the 'goto' syntax introduced in 5.3. PHP may have introduced the feature, but that does not mean we should use it.

Comments and Documentation
The Doxygen documentation style is used (it is very similar to PHPDoc for the subset that we use). A code documentation example: giving a description of a function or method, the parameters it takes (using ), and what the function returns (using  ), or the   or   tags.

Use  rather than   as the escape character (i.e. use  ) – both styles work in Doxygen, but for backwards and future compatibility MediaWiki uses has chosen the   to begin the comments, instead of the Qt-style formatting.

General format for parameters is such:. Multiple types can be listed by separating with a pipe character.

Doxygen documentation states that @param should have the same format as phpDocumentor :

@param datatype1|datatype2 $paramname description

For every public interface (method, class, variable, whatever) you add or change, a  tag should be provided, so people extending the code via this interface know they are breaking compatibility with older versions of the code.

PHPDoc was used at the very beginning but got replaced with Doxygen for performance reason. We should probably drop PHPDoc compatibility.

@var: documenting class members
There is a 'bug' in Doxygen which affects MediaWiki's documentation: using @var to specify the class members' type only works if the variable name is appended:

If you don't append the variable name Doxygen will ignore the entire comment block and it will not be included in the docs.

Integration
There are a few pieces of code in the MediaWiki codebase which are intended to be standalone and easily portable to other applications; examples include the UTF normalisation in  and the libraries in. Apart from these, code should be integrated into the rest of the MediaWiki environment, and should allow other areas of the codebase to integrate with it in return.

Global objects
Do not access the PHP superglobals, , etc, directly; use instead; there are various functions depending on what type of value you want. You can get a from the nearest, or if absolutely necessary. Equally, do not access directly; use  if you want to get the IP address of the current user.

Static methods and properties
Static methods and properties are useful for programmers because they act like globals without polluting the global namespace. However, they make subclassing and reuse more difficult for other developers. Generally, you should avoid introducing static functions and properties when you can, especially if the sole purpose is to just save typing.

For example, lots of developers would prefer to write something like: This is because it is shorter and takes less keystrokes. However, by doing this you've made the Foo class much harder to subclass and reuse. Instead of introducing a static method, you could just type: Remember, shorter does not always mean better, and you should take the time to design your classes in a way that makes them easy to reuse.

Late static binding
In PHP 5.3, a new feature called "Late Static Binding" (LSB) was added to help work around this perceived lack of functionality in static functions. However, the usefulness of LSB is debatable among MediaWiki developers and should be avoided for the time being.

Classes
Encapsulate your code in an object-oriented class, or add functionality to existing classes; do not add new global functions or variables. Try to be mindful of the distinction between 'backend' classes, which represent entities in the database (eg,  ,  , etc), and 'frontend' classes, which represent pages or interfaces visible to the user ( ,  ,  , etc. Even if your code is not obviously object-oriented, you can put it in a static class (eg  ).

As a holdover from PHP 4's lack of private class members and methods, older code will be marked with comments such as to indicate the intention; respect this as if it were enforced by the interpreter.

Mark new code with proper visibility modifiers, including if appropriate, but do not add visibility to existing code without first checking, testing and refactoring as required. It's generally a good idea to avoid visibility changes unless you're making changes to the function which would break old uses of it anyway.

Error handling
Don't suppress errors with PHP's operator, for any reason ever. It's broken when  is enabled and it causes an unlogged, unexplained error if there is a fatal, which is hard to support. Use  and   instead. The checkSyntax.php maintenance script can check for this error for you.

When your code encounters a sudden error, you should throw a MWException (or an appropriate subclass) rather than using PHP's trigger_error. The exception handler will display this as nicely as possible to the end user and wiki administrator, and also provides a stack trace to developers.