bug fixing (general programming)

Quote:

Original post by aaron_ds I was wondering, has anyone here, in an attempt to fix some small stupid bug that eludes you, fix many other larger bugs along the way? How bad of programming is this?

LOL. Yes. We've all been there and done that, haven't we?

If you're doubting your programming prowess because of it... step back a bit and try to shape the problem domain better in your mind.

Sometimes, the only way to figure out what's wrong is to fix what you already know isn't right.

Of course.
Bugs can cascade, you know?

shmoove

Cascade is a good term for it. Sometimes I've realised that the way I was doing something was about as good as it gets for a certain method, and therefore fixing it involved a more significant change that rippled through the system. One good reason to use a dynamically-typed language like Python is that you tend to find that the ripples don't go as far, since you don't have to change a load of function signatures and header files.

I love when i find a bug that's so bad i don't understand how the program ever kind of worked. You know, like when it works for almost all input but will crash in certain scenarios. You find the bug and then don't understand why it didn't crash in all scenarios.

Actually I think it is a good sign that you're recognizing and hunting down multiple problems. Often it is best to fix a bug when you're looking at it rather than waiting for later, as it can be very easy to forget what needs to change. And, as has been said, sometimes the only way to find the real issue is to clear up other issues along the way.

Where you should be concerned is if you start ignoring bugs because they're too hard to track down. At that point it's a good idea to step back from the project for a while and recharge. Better to spend 2 weeks fixing all kinds of problems and not fixing the original bug, than ignoring the original bug and not fixing any of the problems at all.

Quote:

Original post by kdogg I love when i find a bug that's so bad i don't understand how the program ever kind of worked. You know, like when it works for almost all input but will crash in certain scenarios. You find the bug and then don't understand why it didn't crash in all scenarios.

YES!

I know exactly what you are talking about... it usually goes like this:

Program is working fine, so you decide to test it with some different input. It completely barfs. So you look through your code, find the problem, and it seems that the problem should have been seriously screwing your program up the entire time.

When that happens, I usually waste 10 minutes finding out why it was working.

Quote:

Original post by thedevdan When that happens, I usually waste 10 minutes finding out why it was working.

10 minutes ? lucky bastard

Quote:

Original post by graveyard filla 10 minutes ? lucky bastard

I remember trying to fix a bug for one and half hours, then gave up.

Just ninety minutes? I've had bugs that took ninety hours (or more) to fix satisfactorily. Usually when somebody took a shortcut that sort of works but ends up being used for other stuff where it's no longer appropriate.

I've spend one and a half at fixing a bug only to find out it contained NULL in the database instead of a valid value.

For anyone working on a large(r) piece of software, it's always adviseable to setup a bugtracker. I personally use mantis and found it quite satisfactory.

Toolmaker

The best way to kill a bug is to fix it when it occurs. I'm talking about the times when you write some code and it works 'for now' so you move on to work on the next section because it's more exciting. Then you eventually forget the bug only to find it cropping up later on after the cascade bugs you were talking about before.

As Toolmaker said, Bug tracking software is good - but I don't think you need to be a large team to appreciate it. Even just a spreadsheet to log all the times you put in a //TODO comment or a //FIXME really helps you to remember the hacks you put into place. If you make a note when you log it, you can see exactly what the bug is, why you didn't kill it and what your state of mind was at the time.

I heard that Microsoft have Patented the automatic listing of //FIXME and // TODO style comments in an IDE environment - meaning that in a couple of versions of VisualStudio we'll be seeing an automatic list of our known bugs.

Quote:

Original post by evolutional I heard that Microsoft have Patented the automatic listing of //FIXME and // TODO style comments in an IDE environment - meaning that in a couple of versions of VisualStudio we'll be seeing an automatic list of our known bugs.

I thought eclipse did that & I didn't think that it was a copy of the VS feature.

Other than that I spent 8 hrs trying to fix a bug in my thesis project (about 3 days before the deadline & a large quantity of the report left to write) --- only to find that in fact I'd specified the order of some verticies incorrectly, so I had two triangles overlapping (there is/was no need for them to be visible, but the positioning had a mathematical relevance)

If you find a bug, write a test to reproduce the bug. The failing test will then be your todo list.

Quote:

Original post by NickB I thought eclipse did that & I didn't think that it was a copy of the VS feature.

I've never used Eclipse, but here's the news item discussing the patent.

Quote:

The patented technology essentially integrates certain comments left in the source code of an application under development with an accompanying checklist. Leave a "TODO" comment in the source code, and an authoring application automatically creates an item in the task list. Check an item off on the task list, and the corresponding source code comment is changed.

I do know that when you use // HACK: in VS.NET 2002/2003, it gets moved into the task list. However, the task list is a little bitch in 2002, since all compiler errors/warnings get shoved into the todo list. That makes it useless.

Toolmaker