|
Last week, I was asked to change an old tasks report, adding a parameter for the completion status of a task. As it was my first task on this feature, I have been advised by the project's analyst that the report was showing only the overdue tasks.
As I moved to find and change the hardcoded status to the one selected on the UI, I've seen a call to a static method Status TaskStatus.GetEnum() , which would translate the selected option to the corresponding value from a Status enum (ok, I know, it sounds obvious). Actually, it was already being applied to the report, but the query was ignoring the status parameter anyway.
Then I decided to look into that method, and found this:
public class TaskStatus
{
public enum Status
{
OVERDUE,
CLOSED,
ON_TIME
}
public static Status GetEnum(string name)
{
switch (name)
{
case "":
return Status.OVERDUE;
default:
return Status.OVERDUE;
}
}
}
Update: added some context.
modified on Thursday, August 26, 2010 11:38 PM
|
|
|
|
|
Looks like the programmer had the specific requirement to increase productivity of task report users
This would have been worse
switch(name)
{
case "":
return Status.ON_TIME;
default:
return Status.ON_TIME;
}
I won’t not use no double negatives.
|
|
|
|
|
There could be a seperate section for
Coding Doh's
The difference between a Coding Horror and a Coding Doh! is subtle. Both involve the desire to slap a programmer in the head.
With a Coding Doh! the programmer wants to slap themselves, with a Coding Horror another programmer feels the urge to administer the slap.
|
|
|
|
|
Unfortunately, I think the programmer didn't remember to slap himself...
|
|
|
|
|
Richard A. Dalton wrote: Both involve the desire to slap a programmer in the head.
One with the hand, the other with a hammer?
|
|
|
|
|
I would assume that the original coder never got around to finishing the GetEnum method. I sincerely hope that no coder would think that this code would actually work!
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Well, I can see how that could happen. You code up a switch statement with one case and a default , then get interrupted by something. By the time you get back to coding, you forgot about that and no one complained, so ...
Not that it ever happened to me, mind you.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
The author of that code has left the company long ago, so I showed it to my colleagues, trying to figure it out, and some of us agreed that he probably had to restrict the report to overdue tasks, and made it in a totally inappropriate place in code.
This feature has not been used till now, when the customer requested the change that finally came to my desk. Again, without restricting, but now filtering the status...
If you're ever curious about the horror, I have deleted the method.
|
|
|
|
|
Which is why TDD is so good. If you get interrupted, run your tests and you know where you are in your coding.
|
|
|
|
|
I was beating my head on the desk all day over a stupid issue of a perl script not getting all of its arguments.
You see... .NET strings can happily contain arbitrary NULL characters. (I didn't know that until today. Beware of this behavior.) Microsoft decided in their infinite wisdom that we programmers would just love to abandon the old NULL termination method where NULL signaled the end of a string. So that means .NET considers NULL a valid character in our strings, even though the definition of NULL is "THIS DATA DOES NOT EXIST and cannot be compared or evaluated." I was compiling a command line by concatenating multiple strings together. You can probably guess where this is going. Yes, an interop issue! Command lines ARE in fact NULL terminated. I use a WINAPI call that gets the short name for a long filename because somebody wrote a Perl script that can't handle filenames with spaces. Being a venerable old WINAPI function that's still with us since the Win95 days, it returns the result as a NULL terminated char array. So I said "return new string(buf)" to get the result as a string, and good old .NET said "Oh, that's okay, we can have NULLs in strings now!" So guess what happened? After I appended that short name to the argument string, everything after it got truncated when I passed it to a command line, and it rained on elementary school playgrounds around the world. Oh, the sadness was overwhelming. So I had to do a .Replace("\0", "") on that string before giving it to the ProcessInfo and all was golden and happy and the birds sang and rainbows issued forth from the heavens.
Case closed.
|
|
|
|
|
djdanlib wrote: the definition of NULL is "THIS DATA DOES NOT EXIST and cannot be compared or evaluated."
To me, that is more an indicator that the "NULL character" is named poorly, not that .NET should exclude it from allowed characters in strings. NULL terminating strings seems silly to me.
|
|
|
|
|
aspdotnetdev wrote: NULL terminating strings seems silly to me.
I agree.
I've had trouble when receiving data from a serial connection.
|
|
|
|
|
IMO one needs to choose one of two extremes for comfort:
1.
use a "printable protocol", i.e. only transmit printable characters, i.e. the ASCII range [0x20,0x7E] and ignore everything else (including tabs, CR, LF, NULL). Every part in the serial chain (drivers, protocol stacks, modems, ...) will let them through unmodified.
2.
use binary data, i.e. make sure your serial path is fully binary and doesn't touch any byte, does not replace CR by CRLF, does not swallow NULL, etc.
I normally start out with #1 as it tends to work right away. When performance would become important, I'd consider switching to #2.
|
|
|
|
|
I was communicating with some sort of device -- I think the terminal server was causing the trouble.
|
|
|
|
|
.Net strings are Unicode and the type of encoding is therefore important. Could it be that, somewhere along the way, the strings are read with the wrong encoding? This easily could produce some strange results.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
That was my thought too. Unicode encoded with UCS-2 will commonly have every other byte NULL. So, yes, you can have NULLs in a string and its perfectly vaid in that encoding.
|
|
|
|
|
Nothing's wrong with strings that can contain embedded NULL s. The fact that NULL terminated strings are so popular is mainly historic. There are times when it's handy or even necessary for a string to contain embedded NULL s, for example the Win32 SHFileOperation[^] function uses strings that have embedded NULL s.
Steve
|
|
|
|
|
Back in my first year of programming, I was in a Visual Basic class, but I didn't like Visual Basic so I spent a good amount of my time coding in QuickBasic 4.5. In my infinite wisdom, I decided that it would be easier to use draw commands to show text on the screen rather than loading a font from the file system. So I created a function that took the top left coordinate of where to draw the string and it would draw the string... with Quick Basic draw commands. As I recall, there was a for loop to split the strings into individual characters. Then, there was a giant switch command on those characters (or was it a chained if statement... hmmm) to decide which draw commands to use. I then fine-tuned each letter so that large groups of pixels would be drawn as rectangles and individual pixels would be drawn with the command to set a single pixel. I was very impressed with my code, which I'm pretty sure was over 400 lines long! You can see it in action in my Tetris game at the link below, which also used only procedurally drawn textures (i.e., no image files were loaded):
Tetris (scroll to bottom of page)
I will see if I can find this chunk of code, so that you can be mesmerized by this astounding masterpiece.
|
|
|
|
|
I don't think I understand how this is a coding horror... I see this as a great learning experience. The more you learn the under-the-hood stuff, the better
|
|
|
|
|
Every coding horror might be considered a learning experience (assuming you learn from it). In this case, I think I learned patience. Doesn't make it any less horrific.
|
|
|
|
|
I agree; not much of a horror. I think its pretty cool actually Not that I'd prefer to do it over using a font, but it looks like you did a pretty good job of procedurally rendered text.
|
|
|
|
|
I did something similar long ago (around 1977): lots of measurements on electronic circuitry, getting automated using a PDP11 minicomputer (RSX11 operating system) and Fortran IV, and results plotted by an HP plotter lacking any (or any decent?) text output capability. So I did create a font, not as a giant switch statement, as a big table of strokes. The result was nice graphics (for that era at least) with labeled axes and legends.
|
|
|
|
|
Luc Pattyn wrote: table of strokes
Visited the massage parlor recently, eh?
Actually, I did something like that for my Cargobay game (listed on the same page as that Tetris game). I stored the game board as an array or something like that. I found that to be somewhat more reasonable than hardcoding the building of each game board.
Luc Pattyn wrote: 1977
They had computers then? I wasn't born for another 8 years.
|
|
|
|
|
aspdotnetdev wrote: They had computers then?
yes, that was the computer era. It ended in the eighties, when they introduced "PC's", which weren't computers at all.
They were a bit large; you could easily fit the content of your wardrobe in them without disturbing much; a 10MB (later 50MB) harddisk had the size of a modern dish washer.
And that was more than enough to drive a pen plotter and more.
|
|
|
|
|
Yup and if you wanted to use any Maths Libraries on a Prime Computer that I used, you had to grab the MathsLibrary, literally!
It was something a similar size to a drum in a washing machine and you had to screw it into the top of the computer. It did have a disk/human interface to make it more interactive, yeah ok it was just a plastic handle but it was bloody heavy with all those disk platters inside.
He took it all too far, but boy could he play guitar!
|
|
|
|