Too clever by two-thirds: code styles for protecting WP files

WordPress’ PHP Coding Standards include the interesting advice that code need not get too clever.

The authors argue that, in general:

readability is more important than cleverness or brevity.

isset( $var ) || $var = some_function();

Although the above line is clever, it takes a while to grok if you’re not familiar with it. So, just write it like this:

if ( ! isset( $var ) ) {
    $var = some_function();

The preferred example uses the familiar if statement, checking a variable is not set before assigning it (to a function, in this case).
The terser version uses the OR logical operator, represented by || to say, as if rendered in English or pseudocode: “either the variable ‘var’ is set OR assign the variable to a function”.

In preferring the longer, less clever version, committing to code which can be grokked by all, the authors reflect the democratic missionary aspect of WordPress culture. Advising readability over clever tricks implies I think two things: code for WordPress should require an average, if sturdy, baseline of knowledge to at least begin to grok, and as a corollary, is considered code that will be read, and hacked with, by a wide audience. The emphasis then seems to be on encouraging comprehension of and play with the code, by keeping the learning curve from getting steeper than it really needs to be. And it seems like a good example of the kind of clever-clogs approach WP seeks to abjure.

What’s this got to do with protecting WP files?

I just noticed an example of the kind of construction the Standards warn against above.
Many plugins add a statement to the beginning of the main plugin file, basically a security feature that says, in pseudocode:
if this file is accessed directly: abort..
thus preventing unauthorised access to the file. There are two constants defined in WordPress core we can use to help us realise the idea, WP_INC and ABSBATH. This gives rise to two different ways you might see this feature implemented.

if( ! defined( 'ABSPATH' ) ) exit;

This is the most common way I’ve seen. In English it means: “if the constant ABSPATH is not defined, terminate the current script”.
Alternatively, I have seen this one around instead:

if ( ! defined( 'WPINC' ) ) {

Leaving aside questions of style and the use of die or exit, how is WP_INC different from ABSPATH?
Seek answers here.
However, and going with the ABSPATH constant for the sake of progress, there is a third style available we met earlier:

defined( 'ABSPATH' ) || exit;

which I spotted perusing and it instantly reminded me of the clever code example cited above. But lets look at it with fresh eyes.

defined( 'ABSPATH' ) || exit;

In English, that rather brusquely and abruptly says:

ABSPATH must be defined OR here’s the door

No more needs to be said. Here is a line of code that to me might embody, an almost humourous example, the dictum ‘code is poetry’. In its terse, no nonsense and no fuss way it suggests to me exactly the impression of simple and direct lawgiving you want a from a reliable bouncer or guardian.
So here’s an example I think where this clever construction enhances the pleasure of reading the code. Security should be terse, no?