Tilly and brian d'foy best stated the theory for balance between feature and maintenance. But to add some more concrete decision points to blahblahblah's comments, consider this:
Advanced features of a language really best serve one of three purposes, and usually only one at a time.
In the first case, it goes without saying the performance increase needs to be noticable, not just measurable to be worth the effort of cluttering the code with complexity, let alone the effort of even working out the code in the first place. Then, it should be heavily documented including what the "simpler" code would have looked like in the comments.
In the second case, advanced features can actually make code EASIER to read if done right. Unfortunatly your sample is hardly that. reference = grep, if and map is hardly adding any clarity to the issue. If done right, advanced coding features and techniques can actually **HIDE** code complexity from all except those who really need it. In other words, make the code readable as in a "Coding by Intention" sort of way and leave the complex parts hidden in subroutines that only need to get looked at if you are debugging that actual segment. This leaves the mainline of code more clear. After all, loops come with a certain amount of clutter also (counters, test conditions, etc).
The third case is of course irrelavent to the discussion of production code :-)
Production code is not the place to educate the masses. Neither is it a place for needless obscurity. While many of your points I believe are valid, this particular code sample does not qualify. I think your philosophy is valid if tempered with the rules above and those mentioned by blah-cubed.
In reply to Re: "advanced" Perl functions and maintainability
by KeighleHawk
in thread "advanced" Perl functions and maintainability
by geektron
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |