Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^3: Should I leave behind beautiful code or readable code?

by BrowserUk (Pope)
on Apr 01, 2007 at 08:26 UTC ( #607684=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Should I leave behind beautiful code or readable code?
in thread Should I leave behind beautiful code or readable code?

How would you reformat it?


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.


Comment on Re^3: Should I leave behind beautiful code or readable code?
Re^4: Should I leave behind beautiful code or readable code?
by Cap'n Steve (Friar) on Apr 02, 2007 at 08:19 UTC
    I think some of the replies already posted have been good suggestions. I don't know about you, but spreading that to 3-4 lines and adding the braces definitely makes it easier for me to read.
      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.

      1. 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.

      2. It uses minimal punctuation.

        It utilises the perl interpreters ability to avoid redundant punctuation, to simplify (and IMO, so clarify) the syntax.

      3. 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.

      4. 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.
        Nice post, and it turns out I agree with most of your points. When I said to spread it out to multiple lines, I was only referring to adding whitespace (I, too, hate throwaway variables), something like in this post. I like the fact that it separates the different actions a little more than usual.

        Just keep in mind that something that's easily readable to the average programmer might be slightly different than something that's easily readable to someone with 7980 posts on Perlmonks. ;)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://607684]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (7)
As of 2014-09-16 03:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (155 votes), past polls