|
Don't beat yourself up. It's called a learning curve.  FWIW, I could not look back at the code I wrote in my first two years without wanting to throw up in my mouth a little bit.
|
|
|
|
|
I'm not beating myself up. I'm beating my old self up. Which is in contrast to my current self, who is quite not idiotic. Well, until 10 years from now when I see my current self as an idiot too. 
|
|
|
|
|
Straightforward Basic code and not even close to a horror in my opinion. The purpose of the routine is clear, there are no wacky algorithms, and it's easy to locate an error, if say a "j" is not being displayed correctly.
And yes, I know that "Else If" would have been preferable and a "Select ... Case" even better.
|
|
|
|
|
I bet it was fast 
|
|
|
|
|
I didn't run any benchmarks, but I doubt running 60 or so IF statements for each character would be extremely performant.
|
|
|
|
|
Hey sir wi juant to iuse ur code in mexico can u ad ń support
RS
|
|
|
|
|
robertosalazar wrote: to iuse ur code
While the above terrible code is an excellent example, iUse™ is a registered trademark of Apple™. Please discontinue your use of this term.
|
|
|
|
|
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 NULLs. 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 NULLs, for example the Win32 SHFileOperation[^] function uses strings that have embedded NULLs.
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. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
