|No such thing as a small change|
We all know how cool it is (clever, intriguing, sexy, etc) to write Perl code that is highly idiomatic, tersely compact, even ethereally abstracted. But this sort of usage will pose problems for maintenance, especially in shops where Perl is only one of several available tools (and not necessarily the predominant one).
*shudder* Where does that horrid "cleverness" mentality come from, anyway?!? What happened to professionalism; the KISS principle; clean, obvious code that doesn't require wasted thought or effort to maintain?
I see so many would-be clever programmers using complex idioms for the sake of cleverness; playing games with scoping, closures, OO to implement a theoretically elegant solution that's convoluted, hard to maintain, and hard to test.
Sometimes it's simpler to just plain write:
and be done with it, rather than some "sophisticated" mess like:
where the hastily written perldocs for the parser claim that only ASCII encoding is currently supported, and the entire target audience speaks only English, and only has access to 7-bit ascii text terminals. And yes, I've seen code that ugly before! :-(
I see sooo much over-engineering, would-be cleverness, and solving of non-problems in my workplace that I'm perhaps oversensitive to it, but I find that "clever" is far too often code for "writing obfuscated code to stroke my own ego, and protect my job security"; my ex-boss did this for several years, and completely destroyed all semblence of maintainable code here at my company. :-( I'd re-write it, but I'm not allowed to until it breaks. :-(
So, perhaps as a reaction to that, I very much prefer the K.I.S.S principle; make it work, and make it obvious. Be clear on your own time; don't waste your co-workers time on ugly idioms unless the idiom is necessary, and not just "cute". "Cute, clever, and tricky" is quite often the opposite of "simple, obvious, and correct", at least in my experience.