On Sun, 14 Apr 2002 17:17:23 +1000, Ken Williams wrote: > 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?
Not offhand. As I said, I think it's a great book, but it has some examples that are not clear. > 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. Should it matter what language a person programs primarily in? When dealing with corporate coding standards, you should try and make it "easy to read". No exceptions or special cases, if it can be avoided. You want code that almost any programmer will be able to pick up and figure out. Granted, there are some things in Perl that are very specific to it, but the general coding style should minimize how difficult it is for someone else to figure out. Taking the view of "Well, they should just be a better Perl programmer" is not always a realistic option. Code should be simple and easy to read, regardless of the language. Identical? No. Obviously that would be stupid, but as easy to read as possible with the limitations that you have. If there is some useful idiom that would confuse someone who isn't as familiar with the language, and there's another way to do it, where the difference in time it would take is less than the time it will take the new person to figure it out... you go with the more "clear" way... the way that takes the least time overall (thus costing the company less). As long as we're not talking about a complete redesign. No, I'm not talking about doing a regularly expression match manually, there is an acceptable limit to tools to be used. The main goal is that the code should be as easy to read as possible, whether a new programmer or experienced programmer is reading it. And I'm not comparing the times of one to the other with the same code, but rather compare the time of the complex code with one of the programmer options (advanced or newbie) to the time of the "clearer" code. Anyway... just my "unclear" ramblings of clarification while waking up. I still need my coffee. hehehe. :) -Alex ================================================== Email: [EMAIL PROTECTED] Website: http://www.beardeddragon.org/ ==================================================
