Citation needed. This is a popular narrative but I don't believe it; line count is the only thing that has been shown to be consistently correlated with bug count.
Without consulting Stack Overflow, describe the “...” operator in Perl.
As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space.
Clarity is far better than terse code that suffers from leaning toothpick syndrome.
> Without consulting Stack Overflow, describe the “...” operator in Perl.
I don't know Perl. But I'm prepared to do that exercise for APL if you want.
> As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space.
That's exactly what I'm disputing. We know that bug count correlates with line count, and that the chance of bugs increases greatly once a function or class no longer fits on a single screen. So I suspect that squishing five instructions together inside a ternary operator actually makes for fewer bugs.
Whereas I have seen too-smart people creating bugs by cramming things into one line because the brevity required means you end up with hard-to-visually-parse clusters of brackets, braces, and whatever other punctuation your chosen language allows (is that a minus operator, is it negating a value, or is it a range in a regex?).
Bugs are correlated to line count because code complexity drives line count and bug count.
It’s not the number of lines of code causing the bugs, it’s the complexity of the problem causing the number of lines and number of bugs to grow independently of each other.
> We know that bug count correlates with line count
Statistically maybe, but when it comes down to it, clear code > compact code hands down.
Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies.
I'm not smart enough to be able to read and understand a nested ternary or other examples of clever / compact code.
> Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies.
Anyone who's seen an enterprise Java codebase knows there's a third way: so verbose that no-one can tell whether there are any deficiencies, even if each line in isolation is "simple".
I think we vastly underestimate the importance of sheer code length. Being able to comprehend the function, class, or program as a whole makes a lot more difference than whether nested ternaries or the like were used, IME.
And yet most Perl programmers I know do not work in mailing houses so they have never needed to use “...”.
I have worked with brilliant people who still have trouble figuring out the ternary operator, and people who should know better who construct ternary operators with five levels of parentheses, causing deciphering of the intent to be impossible.
So I choose Alexander the Great’s approach to solving the Gordian Knot: slice it open and remove the complexity to multiple layers that mere mortals can understand.
PS: I notice you failed to explain the operator yourself. Minus five points to Slytherin.
Indeed. That was because smart-matching in Perl was symmetric.
The smart-matching in Raku (formerly known as Perl 6) is asymmetric and customizable. If you write:
a ~~ b
you are effectively executing:
b.ACCEPTS(a)
In other words, the right hand side of the smart-match is responsible for accepting the left hand side. So as a developer of a class, you can add your own ACCEPTS (multi-)method to govern how your class will handle smart-matching.
