Stupidest Programming Mistakes

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

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

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

[aaeamdar]

I had this:

auto_mode = ~auto_select1 + 2(~auto_select2) + 3(~auto_select3);

Where auto_mode is later used in a switch{case:}, and auto_selectNs are variouss rc_dig_ins.

Can someone spot the error there? Yeah, 2() is not a valid method. So I changed it to this:

auto_mode = ~auto_select1 + 2*(~auto_select2) + 3*(~auto_select3);

And it still didn't work. Gee whiz. What is wrong now. It gives me a run-time unexpectedness glitch where auto_mode is calculated to be 246 or some nonsense like that. OK, fixed that by not using the binary complement and instead used the logical complement (in a #define) and it works.

In another one we had:

printf("Some motor values %d %d %d", 1,2,3);//Whatever

And nothing was printing. Gosh, that sure was weird. Well, it turns out that we failed to import stdio.h (or anything else that gives us access to printfs). And then, to make things worse, the C language is so incredibly stupid that all it gives you is a warning because it's not prototyped. Since we had been using some other methods that weren't prototyped (may have been a few in Kevins Code) those warnings got mushed in with the others.

Thank goodness for Java.

Paul Dennis

[Jake M]

How about spending an hour trying to decipher a run-time error and systematically commenting all of our added code up to that point, only to later find we were compiling with the 2005 FRC settings instead of 2006?

Oh, and this isn't really a programming error, but I still think it's up there as stupid. In our third or fourth practice match last year, our robot suddenly started smoking out on the field. We had used a large ribbon cable to wire the camera and dozens of switches throughout the robot for use in autonomous mode to sense and pick up tetras, and cap them, which had been working perfectly. As it turns out, several of the spare wires, which was about half of the cable, that had been cut off from removed sensors and never removed from the electronics, and that included several five volts and grounds, had brushed up against the frame, which, simply put, melted the entire cable and fried our camera.