Why check JavaScript and CSS files with PHP_CodeSniffer?

Websites and browser-based application interfaces are getting richer. This isn't new, but it's certainly increasing and is now a much higher expectation of popular sites and software products. This means more JavaScript and more CSS and it often means much more advanced JavaScript and CSS than PHP developers are used to.

PHP may power the guts of your application, but the interface has moved on. It's not just a heap of hard-coded HTML output via your PHP template engine with a few JS and CSS files included. It's now a proper grown-up rich user interface with all sorts of trickery and fanciness. And PHP developers are having to add JavaScript and CSS to their everyday toolkit.

The days of JavaScript development and CSS styling being a nice change for a PHP developer are gone. It's quite likely you are doing more JavaScript and CSS work than PHP for much of the time. You know PHP and it's easy to implement the basic functionality you need quite quickly. But the interface takes longer. Everyone sees your interface code and it has to run in a range of web browsers.

You'll probably spend quite a lot of time working on interfaces before having to head back into PHP to make some functional changes. And this is exactly where coding standards come in handy. You are necessarily having to change between different development languages and all PHP developers on your team need to be able to produce good quality JavaScript and CSS, no just a select few.

PHP_CodeSniffer has support for checking JavaScript and CSS files in addition to PHP source code. It does this by using custom tokenizers to make JavaScript code look as close as possible to PHP code to the sniffs. CSS code looks different but sniffs are written in the same way as PHP and JavaScript sniffs and can listen for special token types that PHP_CodeSniffer creates.

So here is the main benefit of using a PHP_CodeSniffer standard that checks JavaScript and CSS files; consistency.

Just like PHP code, developers tend to write JavaScript and CSS in whatever style they are used to. I believe consistency is much more of a problem with these file types because developers can be lacking knowledge, reverting to copy/paste jobs from the published code examples, or possibly just focusing so much on this new code that they forget that their code will need to be maintained by others. And then there is the fact that the JavaScript engines are pretty forgiving and you can seemingly write code however you please.

PHP developers are really embracing quality assurance processes like unit testing and coding standards. Don't leave the basics behind when you leave PHP behind to work on an interface. Keep your code clean and consistent and follow a coding standard so your whole team can read and maintain your code more easily.

But consistency is not limited to code created by multiple developers in a single language. A good coding standard can actually make your PHP and JavaScript code look similar, providing consistency between languages. This makes it much easier to switch between PHP and JavaScript code, either for writing code or just reading it during debugging, and is equally as good for fast switching throughout the day or long stretches spent coding in a single language.

A nice side-effect of using a good coding standard that has support for JavaScript and CSS checking is that it can find errors in your code that can cause browser compatibility issues. This is something PHP developers don't think a lot about when doing day-to-day PHP development, but it is something vitally important when working on interfaces.

So what do I recommend? PHP_CodeSniffer of course, but potentially a more strict and comprehensive standard than the default PEAR standard. The PEAR standard does not check JavaScript and CSS files and doesn't included sniffs that hook into the 3rd-party JavaScript lint tools. The Squiz standard does all this and might be a good option for you if you are deciding on a standard to use. It is very strict (121 sniffs as opposed to 26 for the PEAR standard) but I do believe it helps produce very good code and it is extremely well maintained. Or you can always build a custom coding standard as well, pulling sniffs from the Squiz standard as required.

Whatever path looks best for you, I encourage you to make a JavaScript and CSS coding standard part of your development kit. You can use PHP_CodeSniffer to enforce it in the same way you check your PHP files, so there is really no excuse any more.