Coding Standards: Humans Are Not Computers

The Computer in Society - April 1965

This is part rant and part poking fun, but I’ve grown weary with the sight of source code running through phpcs for PSR-2 compliance and finding that it’s riddled with dozens and dozens (and dozens of dozens) of errors and an apparently infinite number of warnings. If I actually fixed all the reported problems, I’d drive myself crazy. I’m not crazy. I’ve avoided insanity because I quit using a coding standard. It’s too much and I freely admit it: I loathe coding standards.

Or do I?

The problem with coding standards is not the notion of following conventions to ensure all programmer can quickly read and understand code (and other good stuff), but that someone created a tool to actually check compliance: PHP_CodeSniffer. This isn’t a complaint about the operation of phpcs, but to complain about the mere fact of its existence. Automated tools catch everything. Every minor deviation, every judgement call about what looks neat, tidy or pretty, and every crucial space character found out of place is tallied into a wall of text in your console demanding that all these crucial lapses are fixed post haste. It doesn’t even have the decency to use smilie faces.

Using the cover of such automated tools, we can make judgement calls about code quality, integrate style checks into Continuous Integration scoring schemes, complain about pull requests and patches, and generally impose a time penalty on writing code. There is a point at which common sense morphs into sheer nitpicking, and an automated tool is the perfect nitpicker.

Get Outta My Way!

For me, a coding standard must have flexibility and it must remain invisible 99% of the time. If the damn thing makes sense, a programmer should have it learned inside of a week. If they have it learned then why would they need constant monitoring? Rather than catering to everyone by dictating everything (and then failing to do even that!), a coding standard should instead state a subset of common sense rules that everyone already uses. In otherwords, it should be almost utterly pointless to an experienced programmer. There’s already a good example of this. PHP-FIG has PSR-1. It’s basic, adheres to standard practice, and you’d have to be doing something completely weird to fail compliance. In other words, it’s perfect.

Beyond PSR-1, we then have PSR-2. Plug PSR-2 into PHP_CodeSniffer and a gateway to Hell will spawn. Most of the standard itself is actually quite logical. In fact, most of it is! The problem is when PSR-2 descends into seemingly trivial matters or omits specific use cases, and then implicitly demands total unquestioning obedience. The trivial matters are those that just never occur to me as being problematic (yes, that would be “opinion”) or which my editor does by default. The omissions are cases where PHP_CodeSniffer feels the need to fill in the blanks, or worse, where an interpretation of the existing wording is in doubt. Both fill my screen and CI reports with utter junk (which is more opinion).

Am I expected to waste my time fixing this junk? I don’t think so. I have better things to do like writing more code, more tests, more documentation, and more rants about the state of security in PHPland. Perhaps eating and sleeping in between .

PSR-2 !== PSR-2

What h

Truncated by Planet PHP, read more at the original (another 4322 bytes)

more