Stupidest Programming Mistakes

[Matt Krass]

Alright everyone, let's have a collection of this seasons dumb programming mistakes, it'll be educational, and fun, and maybe I won't make as many dumb mistakes after seeing all the ones possible!

My gyro code was broken because I always checked to see if the output was greater than zero, and if so, set it to zero.....no wonder the robot always spun to the right...

if(GyroSample > 0)
      GyroSample = 0;

Two days troubleshooting that one, thanks to Drew Shapiro from 417 for spotting it.

[ForgottenSalad]

No specific code snippets, but there's been plenty of times where I've tried to compile and gotten 10 or more syntax errors... only to realize I'd left out semicolins on every single line I had added that needed them.

I did, on the other hand, sit there for hours today trying to find out why digital_io_01 wasn't working... Only to realize that I wanted rc_dig_in01

[radicalnerd]

last year somebody deleted +127 at the end of our speed scaling code. it shot backward rather quickly.

[Tureyhall]

Originally Posted by radicalnerd

last year somebody deleted +127 at the end of our speed scaling code. it shot backward rather quickly.

and just today, we couldn't figure out why one of our 3 way switches was giving funny results. I kept checking the code, commenting out things i thought might be the problem, and it turns out i reversed the wires on the switch when i unplugged it to mount it.....

[Eldarion]

Originally Posted by ForgottenSalad

No specific code snippets, but there's been plenty of times where I've tried to compile and gotten 10 or more syntax errors... only to realize I'd left out semicolins on every single line I had added that needed them.

I did, on the other hand, sit there for hours today trying to find out why digital_io_01 wasn't working... Only to realize that I wanted rc_dig_in01

Been there, done that, chewed up two limit switches in the process...

One of the most aggravating things I have run across to date is actually an IFI stupid mistake from 2005. They threw in a while loop, looping 20,000 times, every time new data came in from the camera. This caused the code to take practically forever to execute, but somehow didn't trigger the BLROD. Commenting out the while loop fixed the problem without damaging camera communication; I wonder why it was in there in the first place?

[Tom Bottiglieri]

Ehem...

http://www.firstwiki.org/media/2/2e/RobotAttack.avi

[Donut]

This is easily the worst mistake made this year.

Else (current_state == enabled && last_state == disabled)

It took us 3 hours of staring at it to realise you can't put conditions on an else.

[kaszeta]

Worst ones I've seen on our team:

1. Our variation of "when robots attack", when someone re-routed the shaft encoder harness to where one of the CIM motor chains could suck it in, resulting in one of the shaft encoders zeroing out while the other incremented, causing a wild spiral while folks are falling over themselves to hit the disable switch on the OI.

2. Various spastic responses from leaving the backup battery off the bot and having the motors draw enough current to reset the RC, causing very, spastic results.

[Andrew Blair]

Last night, tried to get my drive code lookup table to compile. Turns out that I did everything right...except NAME THE STUPID THING!!! Thanks to Alan Anderson for catching it.

[ForgottenSalad]

Originally Posted by Tom Bottiglieri

Ehem...

http://www.firstwiki.org/media/2/2e/RobotAttack.avi

That's why you don't use the screws on the serial cable.

[6600gt]

if(joyin - pwmout > rate)
pwmout = pwmout + rate;

joyin - pwmout could be negative but they were all unsigned variables so it never looked at nagatives. So for example it would still execute when (-10 > 5)

Took 2 hours to realize that!

[Mike]

I won't mention the hundreds times I've forgotten a semicolon, I'm sure that's all too common.

So I'll mention the time I was debugging a version of code and wondering why the printf's weren't working. Turns out I was downloading the old (buggy) version of the code

[theycallhimtom]

Working on code for a few days working through all the bugs. Then when it coms time to use it a few weeks later I have lost the code and have forgotten how I fixed all the problems I came across. So I had to redo the code and attempt to remeber how I dealt with each error.

Also assuming that ints were 32 bit caused me some pain.

Oh and almost every day when I download code to the robot I download from the wrong project and realize it a few mins later when the printfs are all wrong.

[Eldarion]

One of the things that keeps tripping us up is that the MPLAB compiler does not follow standard C data type promotion rules.

For example, given the statement below, standard C would promote both data types to integer, then multiply. The MPLAB compiler, however, multiplies a and b as unsigned chars and then sticks the result in the integer value, resulting in an overflow where you least expect it!

unsigned char a = 127:
unsigned char b = 127;
int result;

result = (a * b);

[seg9585]

We've had QUITE a few:

to convert angle radians to degrees:

int tiltdeg = tiltrad*( (int)3.14 / 180 );

hmmm, no wonder why we kept getting "0" as a tile angle...
and oh yeah, it shoulda been 180/3.14 to begin with...


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...

and dont know what we were thinking here:

if(TILT_SERVO > Tilt_Servo_Max)
TILT_SERVO = Tilt_Servo_Max - Tilt_Servo_Min + Step_Size;

um, I think we were trying to have the camera search in the last area it saw the light if it immediately loses it too high...but um.. Tilt_Servo_Min = 0 and Step_Size is greater than 0...