Every Friday there is a knowledge sharing session at Logezy called “Disco”. As the name implies it is a package of fun-filled entertaining sessions.

My Name is Prasanth Premzon and as the first person presenting for the Disco, I was so confused about which topic to present. Finally, I decided to present on “The importance of coding standards”. In the current scenario, I found that the mentioned topic would be very useful for my co-workers.

Once I was in front of the audience I was nervous but it did not last more than 5 minutes. Then I was confident and presented well.

This forum gives us an opportunity to become good presenters along with sharing our knowledge.

An overview of the topic follows.

Best practices of Laravel and Coding standards

Setting a coding standard is very important in team development. Agreeing on one coding standard helps keep your code neat and easy to read and also makes it easy to see the difference in your code when reviewing them.

Below, a line graph represents the difference between dirty and clean code.

Image representation speaks a lot more than a vocal explanation. By analyzing the graph we can conclude that the clean code is better than the fast and dirty code even though it takes time. But in the long term, we get more profit from clean code.

Unfortunately, coding standards for PHP are different between frameworks and PHP versions. For example, method names are to be written in various styles, such as camelCase, snake_case and so on. Rules for naming namespaces and classes and how to use indents and spaces are also different. In this article, we will introduce several well-known PHP coding standards.

About PSR
PSR is a standard established by PHP-FIG(PHP Framework Interop Group). PHP has various frameworks and libraries such as Zend Framework and Symfony, but all have slightly different coding standards. So PHP-FIG, having involved members from each framework, established a coding standard that could be used for all PHP frameworks…PSR.

PSR consists of several standards such as PSR-1, PSR-2, and PSR-4. PSR-0 and PSR-4 are coding standards for PHP’s autoloaders, and PSR-1 and PSR-2 are basic coding standards. Currently, PSR-2 is becoming the most common coding standard for PHP.

PSR-0 and PSR-4
PSR-0 and PSR-4 are both standards concerning namespaces, class names and file paths. Since October 2014, PSR-0 has been deprecated. PSR-4 is now recommended as an alternative. https://www.php-fig.org/psr/psr-0/ Since PHP has an autoload mechanism, each class name with a namespace must have one corresponding file path.

In PSR-0, the following rules are defined for the correspondence between class names with a namespace and file paths:

Replace \ in namespaces with directory separator /
Replace _ in class names with directory separator /
Add .php to the end
For example, correspondence between class names and file paths are as below:
Class Name with NamespaceCorresponding File PathNotes\vendorname\namespace\ClassName/project/path/namespace/ClassName.php\ are replaced with /\vendorname\name_space\ClassName/project/path/name_space/ClassName.php_ in namespaces don’t have any special meaning\vendorname\name_space\Class_Name/project/path/name_space/Class/Name.php_ in class names are replaced with /

PSR-4 is a new standard replacing PSR-0. Major changes are:
_ in class names don’t have any special meaning
Therefore, file paths corresponding to \vendorname\name_space\Class_Name are
PSR-0: /project/path/name_space/Class/Name.php
PSR-4: /project/path/name_space/Class_Name.php
Why there are both PSR-0 and PSR-4
Namespaces for PHP were implemented from PHP5. Namespaces don’t exist in previous PHP versions. When there were no namespaces, there was a problem where class names often conflicted.

For example, you couldn’t define a class named ‘Mysql’ if there was another class defined by that name in one of your imported libraries. In such situations, the common practice was to add a prefix with the project’s name, like Zend_Mysql. PSR-0 made it able to handle such class names with prefixes like namespaces.

Like this, PSR-0 is a standard made to work with older codes. Even though it is deprecated, there might be a chance PSR-0 is more suitable than PSR-4 when using old PHP. However, using PSR-4 is recommended for new projects.
PSR-1 Basic Coding Standard
The more basic parts of PHP coding standards are defined in PSR-1. For example:
Only <?PHP or <?= are allowed for PHP tags
Files must be in UTF-8 without BOM(Byte Order Mark)
Namespaces and class names must follow the standards in PSR-0 and PSR-4
Class names must be defined in UpperCamelCase
Class variables must be defined in UPPER_SNAKE_CASE
Method names must be defined in camelCase
Standard functions in PHP are defined in snake_case, but in PSR-1, method names must be defined in camelCase. There are no explicit rules for variable and property names, so you can use whichever style you like, but it is noted that they should be consistent. For example, defining normal properties in camelCase and static properties in UpperCamelCase like below:

class Something
public $normalPropterty;
public static $StaticProperty;

PSR-2 Coding Style Guide
PSR-2 is an extension of the PSR-1 coding standard. Some examples of its contents are:
You must follow PSR-1 coding standards
4 spaces must be used for indents. Using tabs is not allowed
There is no limit to line length, but it should be under 120 characters, and best if under 80
You must put a newline before curly braces for classes and methods
Methods and properties must be defined with abstract/final first, followed with public/protected, and finally static.
You must not put a newline before curly braces in conditional statements
You must not put any spaces before ( and ) in conditional statements.
Defining Classes
You must put a newline before { in class definitions. Also, extends and implements must be written on the same line as the class name.
class ClassName extends ParentClassName implements Interface1, Interface2
// Class definition
If there are too many interfaces for one line, you should put a newline after implements and write one interface per line like below.
class ClassName extends ParentClassName implements
// Class definition
Since there are quite a few standards that recommend writing { on the same line like class ClassName {, this may be a style which you haven’t seen before.

Defining Properties
In PSR-2, you must not omit public/protected/private modifiers. In PHP, properties become public if these are omitted, but because it is hard to tell if one purposely omitted these modifiers or they just forgot, you should always explicitly write public. The static keyword comes next. You must not use var when defining properties because you can’t add any modifiers to var.
class ClassName
public $property1;
private $property2;
public static $staticProperty;
Additionally, you must not define two or more properties with one statement. You can define properties in the way shown below but it is prohibited in PSR-2.
class ClassName
private $property1, $property2;

Like properties, you must have either one of public/protected/private and abstract/final comes after them if used. static is the last modifier. You must not put any spaces before and after braces, and you must put a newline before curly braces. Also, you must not put any whitespaces before commas in arguments, and you must put one whitespace after them.
class ClassName
abstract protected function abstractDoSomething();
final public static function doSomething($arg1, $arg2, $arg3)
// …
If there are too many arguments, you can put a newline after ( and write one argument per line. In this case, you can’t write multiple variables on one line. Also, you should write ) and { on the same line, separated by whitespace.
class ClassName
public function doSomething(
TypeHint $arg1,
) {
// …

Please note that you must not put a newline before { in closures.
$closure = function ($a, $b) use ($c) {
// Body
Conditional Statements
For conditional statements,
You must put one whitespace before (
You must not put any whitespaces after (
You must not put any whitespaces before )
You must put one whitespace after )
Also, use elseif rather than else if.
if ($condition1) {
// …
} elseif ($condition2) {
// …
} else {
// …

Be careful, else if and elseif are not the complete same things. elseif is one statement by itself, but else if on the other hand is interpreted as an if statement in the else of the first if.
if ($condition1) {
// …
} else if ($condition2) {
// …
} else {
// …

The syntax above is actually interpreted like below:
if ($condition1) {
// …
} else {
if ($condition2) {
// …
} else {
// …

For switch statements, case statements must be indented once from switch, and bodies for the cases must be indented once from case. When not breaking after any kind of operations in case, you must write a comment.
switch ($condition) {
case 0:
echo ‘First case, with a break’;
case 1:
echo ‘Second case, which falls through’;
// no break
case 2:
case 3:
case 4:
echo ‘Third case, return instead of break’;
echo ‘Default case’;

After establishing a coding standard, we’re sure there are cases where your codes are checked by code reviews, etc. to ensure they are being followed. Unfortunately, having humans check the codes usually takes time and effort and result in overlooked mistakes. A tool called PHP_CodeSniffer, which automatically runs checks about coding standards, can help solve these issues.

Finally, I would like to say thanks for being here, and I hope this Blog helped you somehow to improve your coding style.

Thank you all

Please follow and like us: