Best practices in PHP

There has been always a fuzz about the best practices to be followed while programming in PHP. Unlike Python, PHP doesn’t add any restrictions or has any hard and fast rule for indentations. Be it naming conventions for class names or functions or be it positioning of braces; each developer follows his own standards as per his convenience. While technically it doesn’t matter how you indent your code or follow which naming convention but it does makes difference to the readability and also can be tedious for any new developer or other members of your own team who are trying to understand your code.

In today’s blog I’ll list out some of best practices that we explicitly ask to any new developer coming on board. Some of the points are bit subjective and some of you may disagree (especially use of underscore over camelcase) with few. But this what we have been following for quite a while now and have never faced any issues till date.

Naming Convention: Use under_score instead of camelCase

Since there may be more than one developers working on same project it’s better if a naming convention is final upon at the beginning and the same is followed by all throughout the project. The debate between which one is better, underscore or camelcase, has been going on for ages. (Without taking a diplomatic stand) Our personal inclination is towards underscore

So instead of

below works for us

For function names instead of

we would go for

While camelcase is easy to type but for readability purpose underscore is a clear winner.

File naming convention

In accordance with the naming convention for classes and function below is what is recommended for file naming

Instead of

we prefer

Avoid echoing HTML code

Below is a bad practise

Best way to do would be

Turn off error reporting on production

If you are using a framework like PHPasap make sure you turn off debug mode in config file. If developing without framework make sure you suppress all errors and warnings on production

Develop with all errors and warnings reporting ON

If you are using a good framework chances are quite high that the framework does this for you. If you are on your own then make sure you explicitly turn on warnings while developing on your local machines.

​Database logic to be written strictly in model

Instead of writing any database query in your controller let your models handle them. If you write a database query in a model function other controller can reuse the function thus following DRY(do not repeat yourself) principles.

So, instead of below

Go for

While it may be tempting to write database queries in controller and also former approach above may seem more convenient; in long run this will end you up with same line of code repeated in many controllers. And imagine a situation where you have to change the database logic like say along with user ID you also need to check the active flag. With the first approach you will have to make changes in all controllers. While with second you just have to change at one place, in model.

Single quote vs double quotes, doesn’t matters

For double quotes PHP has to parse the string inside the quotes (evaluate any PHP variables in string). While with single quotes whatever you type in used as it is without parsing. So theoretically single quotes should take less time than double quotes as PHP doesn’t need to parse anything. But in actual real world scenario this parse time is too negligible to consider. So it really doesn’t matter which one you use; single quote or double quote.

Email addresses for sending mails should come from a function

To, cc and bcc email addresses for sending mail should never be used directly. Instead use a function to return them. This will help you to send all mails to a default email address while testing or on your development machine. So you don’t accidentally send your testing mails to the actual recipients.

So instead of

Use

Validate data before inserting into database

Here by validate we don’t mean anything about SQL injection. As nowadays use of PDO has become common we won’t talk about SQL injection in this article.

Always use a Validation library. Create a set of rules for each input field that you receive from user. If your database column is varchar with 255 length then make sure you validate the user input for character length. If possible turn off JS validation and check if your PHP validations are able to catch all the errors.

Leave a Reply

Your email address will not be published. Required fields are marked *