Well, last weekend my client called me in a panic and said, "It says it found 341 matches, but where the list of documents is supposed to be, it says 'no matches found!'"
Further investigation revealed that this was only happening on some searches, not all of them. Certain search terms would trigger the bug, but not others. It was quite baffling.
I started playing around with the search code, Dumpering various things to the error log to make sure they looked right. They did. I checked the database query logs to make sure the right queries were being executed. They were. I asked the HTML guy if he had changed any of the templates recently, and he said he hadn't, but I decided to check anyway since he's a liar and often forgets to check in his changes before deploying them.
I noticed that the template contained code like this (simplified for brevity):
Found [% numfound %] matches in [% totaldocs %] documents. [% IF results.0 %]
-
[% FOREACH doc IN results %]
- [% doc %] [% END %]
I would expand on this general principle.
Keep scope of variables as small as possible. Use my rather than our, except where needed. The TT equivalent of this is the localization of variables that occurs with INCLUDE and MACRO directives.
Look for edge conditions, and build unit tests for them. In Perl code, Devel::Cover can often help here. When writing unit tests for templates, provide test cases with extremes of data, such as your results array with an empty first element.
--
Oh Lord, wont you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, wont you burn me a Knoppix CD ?
(Missquoting Janis Joplin)
I guess you also might ask why are null (or even blank) titles allowed for a document. To me, this is an example of why properly designed databases, including constraints, etc, are so important. It can mean a lot of these sort of problems simply disappearing. And yet many developers (including myself) often skip over things like constraints, or make them wide open just because it's "easier".
(Of course, either of these points may not be applicable to your particular project, but they're the sort of things I'd be thinking about if I encountered this type of bug).
I would also say if you have stupid HTML guys (and don't we all) consider using a templating system that limits the amount of damage they can doI realize now it wasn't clear from my post, but the bad template logic was written by me, not the dumb HTML guy.
I guess you also might ask why are null (or even blank) titles allowed for a document. To me, this is an example of why properly designed databases, including constraints, etc, are so important.Indeed. Unfortunately, in MySQL, when you have a varchar column declared NOT NULL, and you fail to supply a value, it enters an empty string, which is fale in Perl.
It's also kinda like the C-programmer's idiom of if ( 5 == var ) instead of if ( var == 5 ). That protects against the accidental if ( var = 5 ).
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
(Nods). Makes me wish there was a def as short as ref.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
They don't mean that users are inherently untrustworthy, just that they'll forget what rules they agreed to abide by, and then the software won't work, and they'll call you in confusion, and then their problem will become your problem.
Make your software verify any constraints on user inputs before you assume the input is valid. Suppose the user should enter "T" for true, or "F" for false. Your code should handle the case where someone decides, against all odds, to type "Jello" in that field instead. Because one day, it *will* happen.
--
Ytrew