The PHP Project Guide (2014)

6. Following coding standards

Coding standards are important when working on an application to ensure your code is consistent in design and syntax. For example, using naming conventions for variables like camel caps (textThatLooksLikeThis) or using underscores between words. There are also a host of other ways you can keep consistency in your application. Following a chosen coding standard will ensure that you and anyone who works in your application will understand its design and the code will be easier to work with throughout the development process.

6.1 Zend Coding Standard

The Zend coding standard is taken from the Zend framework and is probably one of the most commonly followed, even if you’re unaware you’re following it. Some of these rules include using single quotes when defining string literals. For example:

1 $name = 'Billy';

Coding standard like Zend often get down to the nitty gritty of even defining spaces correctly, such as when concatenating (joining) two strings with a full stop. These types of rules also include what should be brought to a new line and what shouldn’t. A very commonly discussed standard for readability of code includes whether or not curly braces should be brought to a new line. Zend says these should be, for example:

1 public function userDetails()

2 {

3 // class code here

4 }

Whereas otherwise this may be:

1 public function userDetails() {

2 // class code here

3 }

There are a lot of people that prefer including the first bracket on the first line, however this is personal preference. The Zend style is in place because it makes the code contained within the brackets to be more easily readable.

6.2 Your own coding style

It’s acceptable to define your own coding style. If you’re working on a project that other people may work on in the future, it’s a good idea to define your style within documentation so this can be picked up and followed by anyone else working on your code. Remember that people sometimes prefer to follow a particular standard, whilst others are absolutely fine with picking up a coding standard and sticking to it in the long run, so bear this is mind when deciding - particularly if you’ll have a lot of people working on your website.

There are a vast amount of programmers who write barely legible code. This is easy enough to get into the habit of doing, perhaps the result of pasting snippets in and writing code so franticly in order to learn or debug errors. If you’re working like this, stop right now! The cleaner and more readable your code is:

1. The more likely you are to understand it when you approach it at a later date.

2. The more likely that other people can read and understand your code quicker, meaning they’ll be able to provide you with better help and support.

3. You’ll learn best practices which are valuable when working in a production environment.

Sort your existing code with a code beautifier

A code beautifier is an application written to change the style of your code immediately by pasting it in and having the application rearrange it for you. These are often not complete, but will give you a better page of code if your code is a mess. Bear in mind that these applications will more than likely not change or suggest different variable names to give better meaning, and therefore you shouldn’t rely on them to fix your coding style. Code beautifiers are often configurable so you can change their output to your taste.

It’s probably recommended to go through your code manually and fix it up, as this gives you practice on the coding style you’re following, whether it be official or your own.

6.3 The heredoc syntax

Not necessarily anything directly related to coding standards, but the heredoc syntax will help you clean up any large multiline output by providing a clean and easy way to write these chunks.

Consider a large SQL query, perhaps 40 lines long. Writing this with the standard notation and escaping characters within these large blocks can become confusing and don’t maintain readability very well. The heredoc syntax avoids this, meaning you don’t need to escape with quotes within these blocks. An example of outputting a large query could be:

1 $name = 'smith';

2 $sql = <<<EOD

3 SELECT `name`

4 FROM `customers`

5 WHERE `name` LIKE "%{$name}%"

6 EOD;

What you write in place of ‘EOD’ doesn’t matter. This is simply the identifier. In this case, it may be better to describe what you’re encasing, e.g. use ‘SQL’ or ‘HTML’.

So, when do you use this? Well, for large HTML output and large queries, it seems like a good idea due to the amount of escaping you may need to do, if not now into the future. For a small query that will require absolutely no variables injected into this, it would be unnecessary to do so. You can find more about this syntax in the PHP manual, including examples.

6.4 Confused about what to do?

Really, as long as you’re being consistent in your code design and it’s readable, it doesn’t matter. Readability is important for other to understand your code, and for you to understand your code when you return to it. Having code that flows well and can be read with ease generally creates a more harmonious experience, although in the short term it can be confusing to decide what to do and maintain your style.

Your code is your own, and it deserves to be written with care and caution so everything looks better and displays an expressive nature. This is one of the main reasons that OOP is favoured when designing your application, as it gives more meaning and structure in an expressive form. We’ll learn more about this later on.