For counterpoint. One wonders how many of those who are advocating dumbing down this simple code, actually had any trouble understanding it? There is a common theme here where people tend to say: I understand it now, but a maintenance programmer (or you) 6 months from now may not. Even though they have just encountered the code for the first time and so are in exactly the same position as the mythical maintenance programmer will be in 6 months from now.

With the exception of the possible abiguity of the use of / / as the parameter to split--which in the light of knowledge of the code, may not be ambiguous at all--anyone not immediately able to understand this code, should probably not be maintaining Perl code anyway.

What is the point of using a Very High Level Language (VHLL), if you mandate not using it's high level facilities? If these people ever opt to use Perl 6, they will only ever use 50% of it facilities, because they will reject the rest on the basis that it is too complex.

You took the words right out of my mouth. Not that I'd have used the orignal snippet as an example of beautiful code...

It's time we snap out of this. If a maintainer can't understand code as simple as this, it's time for him to get educated. People should stop wasting time writing verbose code, and learn more elegant ways to do the same things. It's time they start to learn to recognize the typical Perl idioms, and stop trying to write a shadow of C in Perl.

Who in his right mind would dare to call lines like

for($i = 0; $i<$max; $i++) { ... }
[download]

"simple" and understandable? It's verbose, it's ugly, it's impossible to read, and the only reason why people think it's readable is because they have learned to read it. And to be honest, it probably took them a relative long of time to learn it.

It's time to learn something else.

Isn't this the point of comments? I mean, so you can write code, which ... well is almost by definition not natural language, to do something, and then put a comment by it to explain how and why it does it?

I don't care what a line of code does. I do care, that someone's taken the time and effort to document or comment what that bit does, if there's _any question at all_ about whether it's easy to understand or not.

BrowserUk++ 'ere 'ere.

I never really thought how patronizing my attitude towards my maintenance programmer is. I'm sure he's good at perl, otherwise he wouldn't have my job ;)

@_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;

Update Spelling does not work that way.

Is cramming everything on one line really a "high level facility"?

The OP asked this question because he thinks it could be easier to understand. True, it's not all that hard now, but why on Earth would you argue against possibly making your successors job easier?

The positives of reformatting it: The next guy might be able to spend a few seconds less figuring out what it does.

The negatives: Will you really cry yourself to sleep at night knowing someone is using some of your code that isn't "beautiful"?

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

1.   When you use split(/ /) are you saying that you know that the data will always be separated by exactly one space character or did you really mean to use split(/ +/) or split(/\s+/) or preferably split(' ') instead?

2.   Why are you using map twice when you only need to use it once?   For example:

return map split( / /, uc, 2 ), @somearray;
[download]

I beg to differ, but I find that neither beautiful nor readable. At the expense of sounding like an old fart, I would privilege readability over beauty, which is, of course, in the eye of the beholder anyway.

Especially for code you write for clients, I would shun dropping braces of maps (the speed optimisation is negligable) and implicit uses of $_. Spell it out:

This makes it pretty obvious that some sort of transform is being applied to @somearray, and that is what is being returned.

I used to omit return until the day I tried to return an anonymous hash reference...

The very fact that you are using map says outright that some sort of transform is being applied to @somearray irregardless of how many parenetheses or braces you apply or whether $_ is explicitly used.

After all, maybe you should try something like this

sub MySub
{
    ...some stuff...
    return map { split(/ /,$_,2) }
           map { uc } 
           @somearray;
}
[download]

Please pardon this disjoint response. I've been gnashing my gears looking for a clear way to make my points, but I can't seem to tie it all together. Rather than giving up, I'll just break out the major bullet points I was working on:

The return statement is perfectly understandable from my point of view. There is nothing tricky|useless thing there if, as presented, most often the result is assigned to an array (or, list variables). If the end result will be assigned to a hash, presence of a fat comma in the left most map may give a hint (to the "non-initiated").

(A few minutes later: Let's try to find out the extent of my ability to write about the usage of fat comma as obliquely as possible.)

Readability is the sole definition of beautiful. There is just a question about what's readable for whom.

I agree with what I believe is the spirit of this post.

Even if I'm not an expert in a language, the code should be written clearly enough that when it says

$x = function($a, $b);
[download]

a reasonably intelligent person can correctly understand that 'function' is acting on $a and $b to produce result $x, for example. Then go find out what 'function' does.

If a reasonably intelligent person can't even get that from the code without knowledge of all sorts of arcane idiosyncracies of the language, then we mustn't be surprised when IT managers reject Perl with that tired old refrain about it being unreadable

Perl's 'beauty' may just be it's own downfall.




Forget that fear of gravity,
Get a little savagery in your life.

    return map(split(' ',uc,2),@somearray);
[download]

That's actually harder to read than the original.

"Surely you're joking, Mr. perrin!" ;)

But since it looked like you might be serious, I have to wonder: in what sense could two chained "map" operators be easier to grok than a single "map"? (Like other replies in this thread, I'll admit I had to pause and think more than I would have liked in order to understand the snippet in the OP.)

One other point that I haven't seen raised yet: if there is a concern about "readability for the sake of maintainability", one should perhaps consider how well the code plays with the perl debugger. I've seen a few threads here at PM where people have remarked on how certain constructs are difficult to debug, because there's no way to break at a reasonable point, or even to step through a section of code effectively.

For the particular code snippet in the OP, some unexpected input -- e.g. in some random element of @somearray, all the whitespace turns out to be "\xA0" ( ) instead of "\x20" (space) -- might make for a tough problem to diagnose in the code as written, and I, as a maintainer, would be inclined to change it (e.g. assign results of first map to an array, assign results of second map to an array, then return that array) in order to look at intermediate results and have some hope of figuring out what's going wrong.

Okay, that's not such a big deal. Go ahead and be compact, and in that regard, "simpler" (avoiding unnecessary looping operations) is better.

I like it a lot (I know, I could even leave out the "return").

My background as a C programmer requires that I always include the 'return' at the end of a subroutine. It's a visual reminder that explicitly states that a value is going back to the caller.

However, in a few months I'll be off to new challenges and I will have to leave this code to be maintained by somebody else.

Should your legacy be "Great code, but it took hours to figure out." or "Great code."? You may be working with these people or their bosses again -- you have no idea how small the world is until you've been working for a few years.

Should I let my pride prevail and leave the code as it is, our should I be merciful to the maintainer and refactor it to something more readable to the non-initiated?

I've heard that "Pride goeth before a fall". :)

I highly recommend a) a comment explaining this cute piece of code, b) the addition of a few (unnecessary, I agree) braces to make the syntax more obvious, and c) leaving the 'return' in.

Other replies notwithstanding, it took me a little while to read through that and figure out what it did. If we assume that the person who is going to maintain this is not as skilled at Perl, they'll probably be stumped. And if they're stumped, you'll probably get the call to interpret the code. At least if you've left something that's understandable, the explanation will be brief. If it's halfway to an obfuscation, that's not going to help anyone.

The only reason I can think of for writing something clever, but difficult to read, is speed. Assembler hacks come to mind, an area of software development that is brutally honest. This isn't such a case. Swallow your pride and leave behind a readable, if somewhat less beautiful, piece of code.

I've one client in particular who drove this decision. They want to be more or less self maintainers, so I made everything as simple as I could for them. The result is that after several years many things are in terrible disarray, still working but not well. Revision control? Forget it. I find out about changes either when they don't work and have to be corrected at a moment's notice, or when new projects intersect with damaged code and much of the damage has to be undone to restore carefully planned interoperability.

So, my vote is for writing the best code even if it's beyond the neophyte and maybe stretches the limits of the moderately skilled. If the owner wants to turn the kid next door loose on it, fine -- either the kid next door or the owner will learn a valuable lesson, depending upon how well it works out.

I think there may be easier ways to populate hashes than your cool map/split...

Any company that hires inexperienced neophytes to maintain code has a bigger problem than code readability--namely that, in a million years, they might get a snippet of Shakespeare.

    return map { split / /, uc($_), 2 } @somearray;
[download]

The short and quick answer to your question is be merciful. For me, that you saw the need to ask predetermines the response.

Were I sitting in your place considering simplifying and expanding code, I would be considering the size, complexity and stability of my_sub[not sic]. If my_sub is stable, which is to say well defined, well implemented and well tested, then the issue is less significant; noone is apt to need to read the function body--an ideal toward which to strive. If the function is large, readability may be helped by the shorter version. If the function is complex, making it easy to read becomes more beneficial to a maintainer.

When I run into functions with which I am unfamiliar, I try to look them up; Perl's builtins are easy to look up so I'd likely just keep the map.

The Perl constructs which I think are more worth avoiding for readability's sake are those based on punctuation. I don't mean the variables found in perlvar, rather things like a dereferencing a hashref slice; I don't see that as so complex just difficult for the unacquainted to look up.

Be well,
rir

A programmer (that is, any programmer who derives any amount of personal satisfaction from his or her work) may be naturally inclined to feel that the some piece of code s/he has just written is really good code. But that sense of "what qualifies as really good code" is prone to evolve over time, and stuff you wrote a year (or even a few months) ago may not measure up quite as well when held against your current standards. If viewed again another year from now, well...

And of course, the direction of that evolution is bound to be influenced by your environment. Different (possibly mutually exclusive) things may seem more important (cross-platform robustness, rapid development, modularity, etc) depending on your recent, current and anticipated situations.

Your sense of what is "readable" and what is "beautiful" will change with age. As others have intimated, you may reach that truly enlightened state where "readable" is "beautiful" and vice-versa.

So for now, put aside the more emotional judgments, just do what you think is "right", and hope for the best.

Amen, brother!

I recently got pulled back to working on perl I wrote 4 years ago. I was doing cute stuff back then, that I thought was Great Code (tm) that I'd be embarrassed to post here. Thank (deity) that I left boatloads of comments in there, or I'd have been hours figuring it out again.

Some pieces of code *are* great, but it may be useless to posterity if someone doesn't have the time (and the comments) to understand it.

My own preference is toward simpler to understand rather than 'elegant' code - mostly because I'm only a casual programmer. Still, with sufficient comments (and a couple of reference books) I've always been able to understand what's going on in a piece of code. You can be as elegant / beautiful / complex / obtuse as you want to be IF you have sufficient comments in your code to make clear what you're doing.

Jack

Comments are good. Do not avoid commenting. BUT... as another reply pointed out, comments have to be maintained as well. I like putting in javadoc-style comments, but I've encountered loads of places where it looks like someone has copied and pasted a function and somehow the comment block at the top describes something totally different from the actual procedure. And I will admit that I just left the erroneous comments as they were in most cases. The goal then is for code that is self-documenting and as far as possible only commenting on data structures, on side effects and any assumptions made about incoming data. In the OP's case, I didn't think the example was too bad and I think splitting it up too much could make it look more complicated and scary than it is.

How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist.
Robot Tourist, by Ten Benson

    return
        map { split(/ /, $_, 2) }
        map { uc($_) }
        @somearray
[download]

Why doesn't anyones code look like mine?

sub MySub
{
    ...some stuff...
    
    #print scalar @somearray;
    
    my @jiggered = map{uc $_} @somearray;
    #print Dumper \@jiggered;
    
    my %hash = map {split(/ /, $_, 2)}, @jiggered;
    
    #print Dumper \%hash;
    
    #{
    #  my $file = 'tmp/hash_dump.txt'
    #  
    #  open my $fh, '>', $file
    #    or die "can't open $file to write: $!";
    #  print $fh Dumper \%hash;
    #}
    
    #email_home('hey, we got to here!');
    
    return %hash;
    
}
[download]

To misquote Buckminster Fuller "If the code is not readable it is not beautiful". You can have both readable and beautiful code and that's what I believe we should all aim for- the single map version of your code given by a couple of earlier posters would match my criteria but depending on the context a comment *may* be helpful too.

"When I am working on a problem I never think about beauty. I only think about how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." - Buckminster Fuller

what is the significance of the first two columns of strings in @somearray? are you creating a hash or a list? what are you offering up as the "readable" alternative?

without changing the expression itself, any of these would be clearer, depending:

my %aliases_for_things = map split(/ /,$_,2), map uc, @somearray;
return %aliases_for_things;
[download]

return map split(/ /,$_,2), map uc, @somearray; # FIRST and LAST names
[download]

my @labels_and_values = map split(/ /,$_,2), map uc, @somearray;
return @labels_and_values;
[download]

my @flattened_pairs;
foreach my $thing (@somearray) {
  my $upper_thing = uc $thing;
  my @pair = split / /, $upper_thing, 2;
  push @flattened_pairs, @pair;
}
return @flattened_pairs;
[download]

"Rejoice, Mechanic!"
the well tuned engine sings.
Beauty is Useful.

I agree with you, but few monks in this thread seems to have noticed that in my OP I wrote "readable to the non-initiated" assuming that for a moderately experienced Perl programmer the code would be readable as such.

Kernighan comes to mind - "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

As a rule of thumb and corollary to that I'd say: Leave behind code that you understand at a glance, even were you looking at it some time from writing it. Others may still have to gnaw a bit - but the uninitiated will learn something, right?

"Readable to the non-initiated" is malleable - initiated to what level? Acolyte, Friar, Hermit? :-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

I downvoted this reply on the basis that downvoting a question because it's "a dumb question", is dumb!

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

So where does DrHyde say it was a dumb question? He simply pointed out that entertaining the idea of leaving some code of dubious merit when you could fix it anyway was grossly unprofessional. I tend to agree with that.

At $work, I have to deal with crappy legacy code written by people who don't know any better, but if one has to ask the question in the first place then there's probably something wrong.

• another intruder with the mooring in the heart of the Perl