We literally don’t ship code that stinks

At Modern Tribe we believe in code quality and strive hard to follow coding best practices wherever we can. Of course, this is easily said but can be a tricky goal to attain in practice.

Today, our suite of event plugins is 10 strong and counting, containing some 35k lines^[1] of PHP code–not to mention a lot of CSS, JS, SQL and various other things. That’s not the world’s biggest codebase by any means, but nor is it the smallest!

Additionally, team members have come and gone since the first release of The Events Calendar (archaeologists aren’t certain of exactly when that was, but most agree it was circa 2010) and each has left their own distinct impression on the codebase^[2].

In this post, I review one of the tools we use to help achieve and maintain consistently high standards across our code–code which we are all too aware you and many others rely on. Introducing … PHP Code Sniffer!

PHP Code Sniffer

The excellent PHP Code Sniffer is just one part of our quality control process and is widely used across the industry. There are actually two different sides to this tool:

• It can scan code to find violations of a defined set of rules
• In many cases, it can also fix the code and bring it into compliance

We’re mostly concerned with the first part–detecting the problems–so let’s start with an example.

https://gist.github.com/anonymous/848adb171d9173a23789

Various things could be said about the above snippet (which simply displays someone’s name when submitted from an appropriately structured form) and an experienced coder will have no difficulty in pinpointing them.

• Crucially, it is insecure: blindly trusting that the user did indeed submit their name and not a malicious piece of code just isn’t safe
• The formatting isn’t very nice (in the WordPress world we love our whitespace!) … of course, this is a highly subjective statement. But on a large codebase it’s important to have consistency and avoid a mish-mash of different styles, which can lead to headaches and confusion.

Framed in the stark light of a blog post this is probably all quite obvious.

In the midst of a coding frenzy as a team member works hard to solve a specific problem covering multiple files, however, it is all too easy to avoid wrapping the body of an if statement in braces or even to forget to sanitize a piece of potentially dangerous data.

That’s the beauty of code sniffer. Using our own custom set of rules^[3] we have dubbed Tribal Scents, we can quickly get a report like this one:

https://gist.github.com/anonymous/f381f3f57d3e1131cc2b

A lot of this is concerned with formatting but it also flags up the lack of validation where we directly output a member of the $_POST array.

When to sniff

Besides ourselves, we’re lucky to have lots of other users who want to contribute to and work on The Events Calendar and contributions are generally made by submitting pull requests on GitHub.

While we won’t necessarily turn down a pull request for some minor formatting issues, the tool does give us a quick way of checking to see if submissions are broadly in compliance with our own coding standards and if there are any critical security issues. We don’t rely on it. We always perform a manual review prior to shipping a new release. However, this new tool does give us a nice safety blanket in these situations.

We also use pull requests internally which means the PHP Code Sniffer is frequently used against our own work, including at the end of each release cycle, where we perform one last scan to catch anything that might have been missed.

Though it’s far from being a silver bullet in the quest to craft nicely written and safe code, PHP Code Sniffer is certainly an important part of the overall effort and we hope that this post has given you a sense of why we do this. And, for those coders and potential contributors who were unaware of it, we hope it has piqued your interest in this excellent tool.

Footnotes

1. Counting source lines of code is hard: for this post I used David Wheeler’s excellent sloccount tool. Sadly however this does not scan CSS or JS (note: the same tool suggests WordPress itself weighs in at 133k lines, so our own event-related codebase is approximately one quarter the size)
2. By way of comparison, The Events Calendar 1.0 contained just 2.5k lines of PHP code
3. Our own code sniffing rules are publicly available. If you’d like to view and even use them in your own projects, then you are more than welcome!