The saying goes that debugging is like solving a murder mystery, where you are both the victim and the killer. This, of course, is a bit inaccurate, since we rarely are the only programmer working on a project.
Cole Tobin brings us a small mystery in C# today, though in this case, the mystery is- how does this even work?
string localDir = "null";
string filePath;
if (save_to_Temp)
{
dir = Path.GetDirectoryName(engineeringDataPushPath);
}
else
{
#if PRODUCTION
dir = @"S:\Documents\calibration\Calibration Certs\" + modelNumber + "\\";
#else
dir = @"calibration cert" + "\\";
#endif
}
if (localDir != null)
dir = localDir;
The middle of this code is a bit of static about trying to guess where a file should get stored, with bonuses for a hard-coded reference to a mapped network drive when running in production, which I'm sure will never cause problems. Even better, they take advantage of the @
"verbatim string" operator, which disables escape characters- mostly. Each string gets a "\\"
appended to the end, which could be a @"\"
instead.
But that's just bad code. None of that is a mystery. The key lines that frame the mystery are these:
string localDir = "null";
...
if (localDir != null)
dir = localDir;
The string "null"
is never going to be equal to the value null
. So dir
is going to always be overwritten by "null"
.
So yes, obvious bug, the code doesn't work, very funny, but where is the mystery?
Cole writes:
Somehow, despite the last
if
always evaluating totrue
, this piece of code somehow worked…
And that's the mystery. This code somehow works- or at least, the code as a whole works. As it's impossible for this code to work, as written, we must assume that this code isn't actually calculating the output path. There's some other code block, potentially more correct, that does the real work.
When you have eliminated the impossible, whatever remains, however improbable, must be the real WTF.