Free PHP course. Sign Up for tracking progress →

PHP: Linter

Since we've learned to write simple programs, let's talk about the very process of writing.

Code must be designed in a certain way so that it's clear and easy to maintain. Special sets of rules - standards - describe different aspects of code writing. Specifically in PHP, the most common standards are the PSR standards (PHP Standards Recommendations) from PHP-FIG. A recommendation is a set of rules designed to facilitate a particular aspect of development (or to solve a particular problem). Currently there are several approved recommendations, each labeled with a number: PSR-1, PSR-2, PSR-3 and so on. You'll gradually become familiar with all of these recommendations as you learn and work. Now let's focus on the two main ones:

  • PSR-1: Basic Coding Standard. This is a set of rules defining how to write PHP code, including how to write PHP tags, and what rules to use for naming classes, methods and class constants. It also touches on encoding, autoloading, namespaces, and sharing responsibility between files. These are basic rules; the PSR-12 standard expands on them.
  • PSR-12: Extended Coding Style. replaces and supplements the obsolete PSR-2. The first thing to mention is that this standard requires compliance with PSR-1 rules. Secondly, it adds many new requirements, for indentations, files, strings, keywords, classes, control structures, scope and other elements.

In any programming language, there are special tools, called linters, which check the code for compliance with standards. One commonly used linter in PHP is the PHP_CodeSniffer.

Suppose we have a file with this PHP code:


// On the next line, the indentation is one tab
  print_r (((8 / 2) + 5) - (-3 / 2));


When you check the file, the linter will find the following errors:

  • Spaces must be used to indent lines; tabs are not allowed — PSR-12 recommends indenting four spaces, and the example above uses tabs
  • A closing tag is not permitted at the end of a PHP file — the standard requires the closing tag ?>
  • Space before opening parenthesis of function call prohibited — when calling a function, there should be no whitespace between the function name and parentheses, and in the code being checked there is one space after print_r name

Fix the code by removing the closing tag, indentation, and space after the function name:


print_r(((8 / 2) + 5) - (-3 / 2)); // => 10.5

This code doesn't violate the rules, and the linter will "say nothing", as it were.

Don't be frightened by the abundance of recommendations and rules. Most of the rules are simple and straightforward. You'll most likely intuitively stick to them in the code anyway. Time, experience, and a linter will help you with the rest ;)


Print the result of the difference between five squared and the product of three and seven. Write the code so that each operator is separated from the operands with spaces.

The exercise doesn't pass checking. What to do? 😶

If you've reached a deadlock it's time to ask your question in the «Discussions». How ask a question correctly:

  • Be sure to attach the test output, without it it's almost impossible to figure out what went wrong, even if you show your code. It's complicated for developers to execute code in their heads, but having a mistake before their eyes most probably will be helpful.
In my environment the code works, but not here 🤨

Tests are designed so that they test the solution in different ways and against different data. Often the solution works with one kind of input data but doesn't work with others. Check the «Tests» tab to figure this out, you can find hints at the error output.

My code is different from the teacher's one 🤔

It's fine. 🙆 One task in programming can be solved in many different ways. If your code passed all tests, it complies with the task conditions.

In some rare cases, the solution may be adjusted to the tests, but this can be seen immediately.

I've read the lessons but nothing is clear 🙄

It's hard to make educational materials that will suit everyone. We do our best but there is always something to improve. If you see a material that is not clear to you, describe the problem in “Discussions”. It will be great if you'll write unclear points in the question form. Usually, we need a few days for corrections.

By the way, you can participate in courses improvement. There is a link below to the lessons course code which you can edit right in your browser.

If you got stuck and don't know what to do, you can ask a question in our community