Maintaining PEAR coding standards is a must for PHP developers who are building packages for official PEAR distributions. It is good practice for PHP software/application developers to follow these PEAR coding standards. Following a unified coding standard ensures consistency and better readability. Also, when working on larger projects with multiple developers, it helps to keep the diffs fewer in a version control system.
For indenting codes, spaces should be used instead of tabs. This helps the code to remain unaltered between different IDEs, version control systems, and annotations. A single consists of four spaces. So one indent is four spaces (not one tab) and two indents are eight spaces (not two tabs) and so on.
Using tabs can have negative impacts. Suppose your IDE is configured to occupy 4 spaces per tab and some other person’s IDE is configured to occupy 8 spaces per tab. Now, if the other person writes some PHP and you open the file in your IDE, you will see a double tabbed code for each tab the other person has used. Many IDEs allow you to configure code formatting so that when you use the tab key, it will automatically insert the number of spaces you set there—this means tabbing can lead to inconsistent code readability.
Also, you don’t need to worry about how many spaces you have to type for multiple nested blocks, i.e. twelve spaces for third nesting! Almost every IDE places the cursor to the next line with the preceding spaces/tabs copied from the previous line.
The recommended standard of character length per line as set by PEAR is 75-85 characters for the sake of better code readability. Though there’s some debate on this, however, setting this limit obviously has some valid reasons.
Always use a full PHP opening and closing tag, not the
<? /* code goes here */ ?> shorthand tag. This eliminates the possibility of using a short echo (
<?= ) tag. The full tag is PEAR compliant and doesn’t leave any server configuration dependency. To use
short <? ?> tag you need to have the PHP short open tag enabled in PHP.ini, where you may not always have access, e.g. in shared hostings.
While coding, one should always try to describe what the purpose is of each block of code. There are two types of commenting in a PHP script file. One is docblock comments, usually found in the file’s header section, the other is non-documentation comments. As per PEAR standards, non-documentation comments are highly encouraged. Both the following commenting styles can be used:
C style commenting /* */
C++ style commenting //
Shell type commenting, i.e. # is discouraged
Constants should be defined in uppercase with the underscore to separate the words.
Variables can either be in lower camelcase without underscores in them or can be in lowercase with underscores to separate the words: $thisIsMyVariable OR $this_is_my_variable are both correct.
The class name should not be used with abbreviated words and the first letter should always be in uppercase. Also, if the class name consists of multiple words, then those can be separated by underscores, but the first letter of each word should be in uppercase. Public and protected class variables, i.e. properties and method names should be in camelcase, and private class properties and methods should be preceded by a single underscore.
Control structure statements like if, else, for, foreach, while, do, switch, etc. should have a space between the control keyword and the opening parenthesis, as opposed to the function definitions which do not have any space between the function name and opening parenthesis. You are technically allowed to use control statements without curly braces, but as per PEAR coding standards, it is highly encouraged to always use curly braces for the sake of readability and less logical errors. The opening curly brace should be in the same line with the control statement with space after closing parenthesis and the closing curly brace should be in a new line. There should be a space on each side of the operators used in control statements.
Splitting the code into multiple lines is a good idea when the line is very long. For example, there may be multiple complex conditions under multiple parenthesis blocks. Those can be separated into multiple lines.
Long ternary operators can also be distributed over several lines.
If function calling with multiple parameters becomes a very long line, then the same can be split into multiple lines as well.
A typical function call should meet the following standards:
For better readability, we can add more spaces before the equals operator in a block of related assignments.
Also, we can add more spaces after the comma and before the next parameter to align the parameters of subsequent calls.
Class names should always start with a capitalized letter and the opening and closing braces should be in new lines. The first line of a class file should be the class namespace (if you are using a namespace). Then the use class statements with a line for each. The namespace statement, the use class statement, and the class definition should have a line gap between them.
Function definition standard follows the K&R indent pattern, the style used in Brian Kernighan and Dennis Ritchie’s book The C Programming Language. Following are the main points that fall under this pattern:
The thumb rule of any function definition is to return a meaningful value and, if not, return a boolean.
The assignments of the values to the keys should be aligned and separated in new lines for multiple assignments. Also, the last element of the array should have a trailing comma for fewer diffs in version control and keep valid syntax once more elements are added.
The rule of thumb for script inclusions is: if you are including a class file without any condition then you should use require, and if you are including a class file conditionally, then you can use include. As per the PEAR standard, we should use require_once and include_once, but Rasmus Lerdorf mentioned on his blog about using include and require only for faster performance. Also, as per the standard, require and include should not be written as functions, because these are statements. Writing as a function doesn’t create any error, warning, or notice.
If you’re a web developer and you want to take things to the next level, then maybe you should join our team at CodeClouds. We’re always hiring PHP developers to join our team of PHP experts. We have offices in Kolkata, Fort Wayne, and Wellington—if you want to join a team of international web development superstars, then CodeClouds might just be your new home.