but spreading that to 3-4 lines and adding the braces definitely makes it easier for me to read.
But the devil is in the detail, hence my question. For example, one of the proposed reformattings (drawn from a post by perrin on the basis that whilst we have long both understood that we differ in these matters, I have, I hope, demonstrated in the past, that I have total respect for his consistancy regarding them.):
...
my @separated = map { split(' ', $_, 2) } @somearray;
@separated = map { uc $_ } @separated;
return @separated;
}
Without in any way admonishing perrin for his preference, I do not agree with the motivations behind this transformation.
Restricting myself to the scant information present in the OP, I would code that line as:
...
return map{ split / /, uc, 2 } @somearray;
}
I believe that this would perform the same as the original in all circumstances that I have considered, whilst ignoring any potential caveats that are not in evidence in the OP. In other words, if the original formulation was correct, I believe this will also be so.
Now, based on those assumptions, I can see no reasons for breaking this down further, or for spreading it across more lines or statements. It is, to my eyes, clear, concise and readable, and as efficient an implementation as it could be without a much greater understanding of the details of the problem being tackled which could potentially lead to a better algorithm through knowledge of the data or how the results of the code are to be used.
This is a reworking of the original code, but a minor one that avoids the unnecessary generation of an intermediate list that the OP has admitted he had overlooked. It also uses slightly different syntax to the other similar reformulations I've seen. Less brackets or braces perhaps.
It is idiomatic Perl code. It utilises several unique Perl VHLL features.
- It utilises implicit parameter passing via $_.
No one beyond 1st or 2nd grade continues to write the following style of English prose:
Jack passed the hat to John. John inspected the hat, and then John tried the hat on. John looked in the mirror at John's reflection and decided that the hat did not suit John. So John removed the hat and then John handed the hat back to Jack.
And thank dog. Literature would be incredibly tedious if we explicitly named what I think(*) is termed the Proper Article at every point in every sentence.
Children as young as 2 or 3 successfully transition to using the indefinite article, him, her or it, in their every day speech patterns, without anyone jumping on their case. Even when there are several concurrent indefinite articles in a single sentence or paragraph, the human mind is, in most cases, entirely capable of discerning which real thing each is being referred to, from context.
I see little merit in eshewing the use of the indefinite article in Perl. To my mind, Perl's greatest contribution to the field of computer language development, is it's application of context. Sure, it doesn't always get it right, but then human speech evolved over many thousands of years. Perl's been around for what 10 or so? And it's only in it's fifth incarnation, and suffers from the yolk of backwards compatility going back 2 or 3 of those incarnations. It hasn't yet had the opportunity to evolve to correct many of those ambiguities. I'm still hopeful that Perl 6 will one day correct many of them.
I firmly believe that brevity greatly contributes to clarity. And that verbosity, as in redundantly, explicitly naming the Proper Article, is one of the problems that makes languages like Java so tediously verbose to write and maintain. Indeed, I would suggest that it (the verbosity), actually contributes considerably to the expense and slowness of developing Java applications that is manifestly evident to anyone who has taken part in a large scale Java project. Or even just read the anecdotal evidence.
(*)Corrections are unnecessary. My point is clear even if my terminology is confused, or just plain wrong.
- It uses minimal punctuation.
It utilises the perl interpreters ability to avoid redundant punctuation, to simplify (and IMO, so clarify) the syntax.
- It doesn't go all out for efficiency at the expense of clarity.
For example, it would (probably) be marginally more efficient to trade the braces of the code block for a set of parens around the arguments to split (for the same golf score), as (I believe), it would avoid the generation of an extra level of scope.
However, the first argument to map is a block of code and I like blocks of code to look like blocks of code. In every other situation in perl, code blocks are delimited, unambiguously by the use of braces. I find the ability, in this one unique situation, to pass a "callback expression" in the form of a sort of bareword string, anomolous. I think it serves very little purpose except as a true example of premature optimasation. I also think that this particular duality of syntax is one of the greatest contributors to the ongoing problems people have with map, and in great part why so many continue to limit (or shun entirely), their use of this extremely useful and powerful VHLL feature.
- It utilises map, inline with the return to avoid the creation, population and destruction of an intermediate array.
So you see, I was not suggesting that there was no scope for reformatting the code to improve it's readability, nor that it had to be done in one line or statement as you earlier suggested that you thought I was. I was suggesting that some of the transformations that were being suggested, indeed all of them that I had seen at the point of my posting, were going much to far the other way, and (IMO) for the wrong reeasons.
I was railing against the notion, in vogue here for the last year or so, that one has to eshew idiomatic Perl; to explicitely state everything; break every part of an algorithm down into result = object.action( @arguments ) phrases; in order to write readable, mainainable code. Whether in the form of the chorus of "You don't want to be doing it like that, you must do it like this!" postings here at PM; or in the attempts to make the PBP guidelines enforcable, and mandatory for all; or anecdotal, perfunctory and capricious application of the phrase "unprofessional" to anything which doesn't measure up to the writers personal viewpoint; I find this notion ill-founded, abhorrant and (IMO) just plain wrong.
Of course, as I've tried to diligently indicate throughout this post, these are just my opinions and no one, but no one, is obliged to adopt them without reading my reasoning, verifying my conclusions, and reaching there own. In fact, I strongly urge everyone to do so.
But, much to my surprise, on the basis of the positive response my first post has received, I'm not alone in my thinking that this orthodoxic movement to deprofessionalise idiomatic Perl has become too strong, and it needs to be countered.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
