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.
| [reply] |
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] |
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] |
| [reply] |