CaolanDix has asked for the wisdom of the Perl Monks concerning the following question:
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: code review?
by sub_chick (Hermit) on Jun 11, 2008 at 00:13 UTC | |
Also, troubleshooting (reading up in your Perl book or searching your issue here) is the best way to teach yourself. When you get stuck or want to improve, this is the place. Es gibt mehr im Leben als Bücher, weißt du. Aber nicht viel mehr. - (Die Smiths)" | [reply] |
|
Re: code review?
by GrinningDragon (Initiate) on Jun 11, 2008 at 00:14 UTC | |
| [reply] |
by CaolanDix (Initiate) on Jun 11, 2008 at 16:47 UTC | |
| [reply] [d/l] |
by kyle (Abbot) on Jun 11, 2008 at 17:50 UTC | |
Ouch. Use strict and warnings!
If you look at perlvar, under $' and $`, it says "The use of this variable anywhere in a program imposes a considerable performance penalty on all regular expression matches." If your performance isn't a problem, don't worry about it. All I would suggest is you use English and name them $POSTMATCH and $PREMATCH since some folks (me, anyway) don't know what they are without looking them up. In this case, you can avoid them completely by using s/// like so:
Note that I'm using the vertical bars as delimiters so I don't have to escape the slash. Putting "?" after the slash means that the pattern will match it if it's there, but it doesn't have to be there. In fact, as I read on, I think that all of your construction of $imagefile could be something like this:
After that, you're checking $path against a bunch of patterns and setting $ImageFilePath according to what you find. For example:
In your regular expression, you escape some characters inside the character class, but that doesn't work as you intend. It's worthwhile to know that \w is the same as [a-zA-Z0-9_], so your whole expression could be:
Again, I used different delimiters here to avoid having to escape the slashes. You could use a data structure for the whole if-else ladder you have.
That might not be easier for you, and if you later have to do something other than a pattern match as a condition, then you'd have to change it back. There's not really anything wrong with the if-elseif-else you have, but they can get to be a problem if they get too big.
Your comment is chopped off. I usually wouldn't want to have that many parameters to a function. At that point, I'd consider passing in a hash ref to it with all the parameters.
This isn't really necessary, of course. It's nice, though, since you can pass your parameters in any order, you can more easily support defaults, and they get a name.
This might be more clearly written as:
Use the three argument form of open to avoid the problems you get if $filename is funny. It's a good idea also to report "$!" in the error message so you know what went wrong when it goes wrong.
Another thing you should consider is using lexical filehandles instead of global ones. You can put "my $hFile" in place of "hFile", and Perl will provide you with a filehandle. You can pass $hFile around to other subs easily, and it closes automatically when it goes out of scope.
There's another one of those variables with the performance penalty. In this case, you can avoid it using capturing parentheses around the whole pattern.
Note that (?:stuff) is non-capturing parentheses. It forms a group, but it won't stuff something in $2 as it would otherwise.
Note that the use "happens" at compile time regardless of whether the sub is called. Some people like to put them in the sub the way you have. There's a discussion of this in Code style advice: where to put "use" statements?
I think what you're calling a $row here is actually a field within the row. Having a variable named $QueryResult and another one also named @QueryResult can be confusing, but it's not too bad in this case since they both live and die close together.
I usually put the program at the top and the subs under it, but that's just style.
I'd add also:
Again, I'd write this as:
At the top you use Carp, but it doesn't look as if you actually use it anywhere. In general, if it works, and it keeps working, that's what matters most. I'd strongly suggest you use strict again, though. If you need to have some global variables, that's not the end of the world, but declare them visibly so every reader knows what they are and what they're for. You have a nice "section" at the top for this, but there's only one variable listed, and I'm pretty sure there are more. I hope this is helpful. I've written a lot here, and I don't have time to polish it all up as I'd like to before posting. If you have any questions about this, go ahead and ask. I'll do my best to clear up anything I've confused. | [reply] [d/l] [select] |
by toolic (Bishop) on Jun 11, 2008 at 18:35 UTC | |
Read more... (710 Bytes)
| [reply] [d/l] [select] |
|
Re: code review?
by derby (Abbot) on Jun 11, 2008 at 11:38 UTC | |
If the code's not too large, post it here. For a more private review based on best practices, look into installing and using Perl::Critic.
-derby
| [reply] |
by CaolanDix (Initiate) on Jun 11, 2008 at 16:41 UTC | |
| [reply] |