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.