There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Looking for code review/suggestions. As mentioned in threads bellow, this is work is for educational purposes.First of all I would like to stress that I have understood your aim and point of view. However I contend that "for educational purposes" goes in the same direction of "using no modules at all". More precisely I would say that these are mostly orthogonal concepts. For example I know next to nothing myself about network programming. Now it happened that I had to perform a simple task of communicating to a device (a webcam) to make it do some actions. I tried with IO::Socket::INET but had a hard time with it and lately resorted to Net::Telnet which basically made my program a one liner, with all of its intelligent defaults... I'd still be curious to try my hand at IO::Socket::INET on that task, for educational purposes. But the situation is quite different from that suggested by your approach. Don't forget that: "CPAN is my programming language of choice; the rest is just syntax." (From Perl 6 is Here Today!) This is especially true if you're having to do with modules in the core distribution, e.g. File::Find. Now, you may want to try your hand at coding a replacement for say File::Find or any other module you like, or a specialized version of it, adapted to the application under consideration... Now, on to the code... Excellent!
My fault, as duly pointed out at Re^2: Find images regardless of filetype extension.: I hadn't noticed it was inside an if clause. However the use of either short circuiting logical operators or of statement modifiers is so widespread in Perl and so typical of it that IMHO a full structure is rarely necessary and I doubt that it would contribute significantly to readability. In any case I would like to stress that I'm expressing here a stylistic preference of mine, certainly not an absolute truth!. (My point here being that the the else { return } is far enough from the test not to be noticed at a glance and put in relation with the former.) Here you're doing twice as many stats as necessary. You're also doing twice as many pattern matchings. Perhaps if you really wanted to follow this approach, may have been slightly better. Also either a pre-mapping to "$dir/$_" or a chdir into $dir may have been advantageous. Incidentally, as far as the former option is concerned, you know that to do it in a really portable way you should have used File::Spec, don't you? (This is just FYI, I use stuff like "$dir/$_" myself all the time.) All in all, and maintaining an approach similar to yours, I may have done: I used string comparisons because they should be faster and they are done on every cycle. Now most file and directory opening functions support lexical handles. Well, that's not strictly true (from the technical point of view), but that's a good approximation to the truth. And with a lexical dirhanle you wouldn't need an explicit close. Well, I can't comment on your whole logic. But rather than having $recurse flag I would try to arrange things in other to have at some point a recursion for @dirs (this hypothetical @dirs not being yours), so that when @dirs is empty simply no recursion happens... Why not instead? (I don't know which is faster, but I suspect they execute at much the same speed, and the latter is more clear, IMHO.) Incidentally, why did you put a label there, if you didn't use it? If is't for documenting reasons, then I get your point and I may agree with you. No problem with this, but why not instead? No need to quote all your variables! Ditto as above! Ditto as above wrt using lexical filehandles. Also, some disagree, but I always recommend using the three args form of open. You may have done this check in your file finding routine on _ so as to avoid a third stat. You may want to just warn and go on to the next one... just an idea! Ouch! It doesn't mach my PNG images, not to say a few other tenths of popular formats, not to mention more exotic ones... Seriously this may be a good reason for using a dedicated module... No need for scalar. No need for the outer parentheses. No need for the inner ones either. No need for the if modifier, and no need for the second statement: is just as fine! Huh?!? Isn't $recurse a lexical variable in your file finding sub? Here you're returning a possibly huge list of files to scan them subsequently for images. I would check them on the fly, that is what I would do in the File::Find 'wanted' subroutine. In reply to Re: Find images regardless of filetype extension.
by blazar
|
|