by Michael S. Kaplan, published on 2007/09/05 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/09/05/4756822.aspx
I have no creativity in my negative assessments of technical issues.
This does not refer to constructive criticism, this is more of the venting phase when something really bad is going on, or about the theoretical implications of a poor design decision that may not even be implemented yet....
In essence, everything that it bad gets categorized in one of three buckets, either it (a) sucks, (b) bites, or (c) blows, and creativity is either non-existent or occasionally applied any associated adverbs or direct objects.
(At some point during the early 90's I did add the term wingnut but that was about people, not technical issues!)
Now when it comes to positive terms, I do get creative and my opinions can vary quite a bit and be quite individualized and include praise when appropriate.
But when something is bad I don't want to dwell too much on it -- better to put it in a category and move on toward something that will actually work.
As you can guess probably, this is not something I would apply to whole products; even the worst of products is a collection of both good and bad ideas, designs, implementations, and verifications.
My categories are lower level than full products for this reason. :-)
Anyway, all of the above was a mildly pointless segue to explain the title. You can probably ignore all the text above the break below this line, unless you are trying to gain insight into why some people think I should be in therapy, as the above probably provides several clues....
So putting aside the irrelevant question of what I believed said head checks bite, precisely, let's get to the important questions:
To answer the first question, when I talk about "head checks" I am referring to the validation done at the very beginning of a function before it gets into doing anything that would impact performance.
This is the perfect place to check for missing or NULL or invalid parameters -- before you crash or give wrong results based on the caller violating the contract of what the function expects.
But as a place to do string comparisons, especially involving case-insensitive whether ordinal or linguistic comparisons?
It truly BITES for those.
Which takes us into the second question, now doesn't it?
I could probably find it easiest to explain why such head checks bite by example. And one need look no further than posts in this blog such as FAT/FAT32 oddness on Win2000, which was a bug in Windows 2000 due to just such a head check (this problem was fixed in XP).
Or I could ignore my embarrassment and point toward Don't forget to test the demos, which was actually mentioned in first draft of the next review as an example of me being sloppy until I pointed out the work I was doing at the time that led top having insufficient time to test the demo! This bug (which still exists in SQL Server) is due to an optimization in SQLS that does its own internal validation of the user name as a head check prior to the slower operation of validating the name in n integrated login scenario. Which may or may not be using either Windows or Active Directory, as I pointed out in 'Need more input, Stephanie!', which makes my whole point about the problem with the head check, which will not match the semantics of either type of comparison and thus it is an inaccurate head check.
Which bites.
But the problem with these examples which you may have even seen before is that they seem too obscure, too easy to dismiss.
Do the examples listed in Michael Kaplan's random stuff of dubious value amount to a reason to possibly impact performance or to change code that has been there for a long time that no one has complained about?
Is it in fact okay to BITE here?
Well, no, it isn't. :-)
So let's take some other scenarios, like accessing network shares where the casing table is different (remember that it is 5.0 in Vista as I mentioned e.g. here and that the share could be pointing to a UNIX box or a LINUX box or a Mac (any version for any of those, too!). Any validation ones does with the casing table via an OrdinalIgnoreCase or ComapreStringOrdinal type comparison may be completely invalid in the context of the data for that share.
Or imagine a jump drive formatted on one system containing data valid by its rules, read by another machine with different rules? Somewhere in the myriad of differences between platforms and versions of those platforms, there is plenty of room to screw things up, badly.
If you make a mistake, there are two possibilities:
There are more complicated examples too if you actually try to do things like convert the case as a form of "easier case insensitive comparison) involving issues with case preservation (hinted at here and here). What happens if you move or copy or worst of all delete the wrong file? When was the last time the backup was run before your function was?
The best answer here is DON'T DO THE HEAD CHECKS whose results are variable depending on the target.
Because any other answer is a bug -- if not now, then one day. At which point your head check will bite.
This post brought to you by ⻭, ⻮, and ⿒ (U+2eed, U+2eee, and U+2fd2, a.k.a. CJK RADICAL J-SIMPLIFIED TOOTH, CJK RADICAL C-SIMPLIFIED TOOTH, and KANGXI RADICAL TOOTH)
referenced by