Stupidest Programming Mistakes

[Matt Krass]

Originally Posted by seg9585

In trying to comment stuff out with "/* */", we realize that we comment out other stuff already commented out using the same method, and whenever it reached that comment's "*/" it would end, causing a bunch of syntax errors throughout the rest of the uncommented code, and we couldnt figure out for the life of us why it was reading that code...

Little trick Mark McLeod showed me for that:

#ifdef //This is actually a comment block, #1
code
code
code
#endif //This is the end of comment block #1

Since the #ifdef is missing something to check, it always fails, so any code in it never compiles, doesn't get stopped by */, quite useful

[Mike Shaul]

The C Programing language has MANY different "issues" with undefined behavior or easy-to-make mistakes that compilers won't usually catch.

This website has compiled 10 (actually more than 10) common mistakes, check it out.

[Goldeye]

My teammate made a great slipup that him and a mentor didn't catch till I looked. Here it is (with the error) in a function for averaging something in pseudocode.

int sum,count;
while(stuff_left)
{
     sum+=stuff;
     count++;
}
if(!count == 0)
     return -1
else
     return sum/count;

[Cuog]

I havent made any hilariously dumb mistakes coding, i have done the condition after the else statement but i caught it quickly and i have also done the good old no semi-colon, but my most hilarious story is from an alumni from our team on his first programming attempt,

Basically to init his PWM values he set them to 0 logically thinking that zero meant no speed, the robot the ran full speed backward over the laptop he was using to program giving it the name "smokey" for ever and now i have to try and fix this old i286 laptop to use for some random off season stuff

[Kristian Calhoun]

this was one that someone els eon our programming team made that i had caught. we kept trying to compile the code and we kept getting an error, it ended up that instead of pwm01 and pwm02, that the other member of our team had put pwn01 and pwn02. we reached the conclusion that you cannot pwn the pwms lol.

[scitobor 617]

For some reason whenever I open a project in MPlab it automaticlly opens user_routines.c from an old version of my code. It took me half of a saturday to figure out way changing stuff in user_routines.c had no effect what so ever, even when I intentionally added errors that should have caused all kinds of compile time errors. I still do not know what is causing this but I now know to check which file I'm editting before I make any changes.

[BrianR]

Today we were trying to do our angle calculations, and we had made a trig mistake. So we changed it and uploaded the code. But for some reason it kept having the same problem. After we changed some other stuff to no result, we happened to notice that the loader was calling the wrong code, and that for some reason, it had built the .hex file to a different spot. Once we figured that out, it worked like a charm.

[Chris_Elston]

    if (varible = 1)
    {
      do this;
    }

Burns me ALL this time....don't forget to use DOUBLE equal signs....

[tpc]

Originally Posted by chakorules

Burns me ALL this time....don't forget to use DOUBLE equal signs....

This is why I always write the constant first, when comparing equality between a constant and a variable:

if (1 == variable)
{
  /* do something */
}

Then if I inadvertently use an assignment rather than a comparison, it's a compile-time error (can't assign a value to a constant).

[ForgottenSalad]

I spent an hour and a half or so trying to figure out why a new revision of our code wasn't working at all today. After switching speed controllers, cables, checking for abnormalities with a multimeter... I realized I had never called my routine. I ended up (stupidly) slamming my fist down on the laptop.

[Chris_Elston]

This is an EXCELLENT idea. Thanks for sharing this.

Originally Posted by tpc

This is why I always write the constant first, when comparing equality between a constant and a variable:

if (1 == variable)
{
  /* do something */
}

Then if I inadvertently use an assignment rather than a comparison, it's a compile-time error (can't assign a value to a constant).

[X-Istence]

Listen to the compiler when it tells you about casting. Don't try to force something to cast, and then lose information. Like going from unsigned to signed ints.

[Idaman323]

Well, It wasn't exactly a programming error, but it made me think it was. Someone, when wiring the bot, plugged the speed controllers into the Relay outputs instead of the PWM outputs. I sat there looking through the code trying to edit, and reload code on the bot for 3 hours.

Our Robot Controler was upside down, so I couldn't see what it was plugged into. Everytime I aksed someone to check the speed controllers, I always asked someone else to check it, Since I didn't wire it. I wasn't sure exactly how it was wired. Finally after getting REALY tired of mesing with it, I lay down under it and looked. I was look and the robot controller to find out the speed controllers were in the Relays and not the PWM. After that, It worked from then on out. It got me very frusterated But now its all good.

[jfelser]

I dunno if this is truly a programming mistake... but testing autonomous (using PID) we forgot to plug in one of the the interrupt pins on the encoders, resulting in a very interesting open-loop control system, and various material damages (the robot LED, the green light, the 6' stack of books the light was sitting on, the desk the books were sitting on, the counter with microscopes behind the desk with the books and light, and my self confidence).

[Brad Voracek]

We've had one major error that took -forever- to figure out.

We had this cubic function for the drive system, since it would increase slower... And it built and all, but when we loaded it an error popped up in the IFI command prompt, all in HEX. It took a while until we realized that victors couldn't take floats @.@

Then we had to change our step(which works very well now, speeds up slowly then stops fast, speeds in reverse slowly but goes to 127 again fast.) from .8 to 1 =P All is good now... also we decided to move our autonomous code to a new file, and leave manual in another... Only to forget to change this
#ifndef __399_Code_h_ in our header file to the name of our Autonomous file @.@ That gave us the same hex error stuff... Oh well! All is good now... Except it seems like our cam is fried. =/... Will be able to test it more tommorow =(

EDIT: After reading tons of the messages here, it seems that those hex errors were actually oversized memory? I doubt we have the new IFI loader so eh... I guess maybe we can go back to our cubic. This works good though, so we'll see.