On Sunday, April 14, 2002, at 05:18 AM, BeardedDragon.org wrote: > The other new guy (I'm also new there) wrote a Perl program. > He's new to > Perl (I am not). Well, there was some obscure nested tertiary operator > with regex's in it. Aparently something he actually got out of > CookBook. > Well, first we told him to only use CookBook for ideas, not > syntax... then > we passed the code around and let everyone enjoy a good laugh. I don't > think he'll make the mistake of writing code that isn't clear again... > especially not a direct copy from the Perl CookBook (good book, > bad habits > taught though).
Hm - I've got a copy of that book, and although I've only looked through a few sections (it's a cookbook, after all) I've found it to be pretty good. I don't suppose you could share the example? > It's like some people think there's actually a performance gain from > writing obscure code, when in reality that's not necessarily true. I > mean, if you REALLY need a performance gain, write that portion > in C, or > some other language that's going to be faster. Otherwise, > leave it clear > to read, and cut down your maintenance costs. Here's a problem, though. Do you mean "easy to read for Perl programmers", or "easy to read for C programmers"? There are some EXTREMELY useful idioms in Perl programming that would probably confuse someone who had never seen the language before. But they can be brief, clear, and fast. Just trying to make the point that you must consider who the maintainers are, and that not everybody agrees on what "clear to read" means. Of course, I agree with you that maintainability is FAR more important than performance in 99% of situations. In fact, it's probably more than 99%, as I've never come upon the 1% yet. -Ken
