Re^3: hash slice ? No thanks, I'm about to return...

so we often have beginner level people looking at stuff and implicit return values really slow them down

It would be faster to take the 15 minutes to teach each of them about Perl's very simple return policy ("last expression evaluated is always the return value") than to require every coder in the world to make up for their lack of training.

Even if you could establish policy for newly written code at your organization, these coders will always be looking at code from the CPAN or from consultants that clearly are not going to put in all of your handholding.

I don't want to suggest that coding standards are categorically silly, but don't try to make Perl look like another language in the standard. Lack of the "return" keyword is both idiomatic and commonplace.

It's a bit like demanding that every sharp corner in the workplace be covered with Nerf foam, just because there are some people who walk around with their eyes shut. No, it'd be simpler to teach them to watch where they are going.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Comment on Re^3: hash slice ? No thanks, I'm about to return...

Replies are listed 'Best First'.
Re^4: hash slice ? No thanks, I'm about to return... by cbrandtbuffalo (Deacon) on Feb 20, 2005 at 14:37 UTC
I generally agree with your point, but when those coders are learning a bunch of other things at the same time (like why it's nicer to pass back a reference than an array or hash), it can be one more thing on their stack. I have some influence on the standards, so I try to pick and choose which Perl idioms I want to push for and which I let go. So, given your example, I guess we've decided that we'll go ahead and put the padding on the corners. At first, they'll run into the table, later they'll go around but hit the padded corners. Eventually, they'll navigate the office (or the code) nearly flawlessly, and even then the padding doesn't hurt them. There are a few drawbacks, but not many. And the additional advantage is we avoid some ambiguity. I think the cool thing is that Perl makes this sort of thing available, even if it is optional. Your padding example is apt because this sort of thing does pad the learning process and 'takes the edges off' the learning curve. These things can be invaluable when you have an office of people re-learning (from a mainframe environment or a non-coding background) or tackling other similar learning curves.	[reply]
Re^5: hash slice ? No thanks, I'm about to return... by rir (Vicar) on Feb 22, 2005 at 19:22 UTC
I agree with Merlyn. But if you want to inhibit your coders' learning of Perl, you should constrain the language to your subset by a required lint process. You should also let them know you are using C, or whatever, conventions. The particular idiom you are trying to squelch is worth learning for fall-through blocks of code used with sort and map. Be well, rir	[reply]
Re^5: hash slice ? No thanks, I'm about to return... by herveus (Prior) on Feb 23, 2005 at 15:08 UTC
Howdy! Among the problems with obsessively padding corners are: You learn not to run into corners faster if they bite You don't have some place to scratch that itch right between your shoulder blades Sharp corners are valuable learning tools in life... yours, Michael	[reply]