Search CompSci.ca
Subscribe
Programming
Delete bugs and broken code
An often overlooked approach to fixing broken code, is to simply delete the broken part and rewrite it from scratch. It might seem counter-intuitive, and a lot of people would be hesitant to delete code that’s already there. It might seem like a step backwards from the solution, but in certain situations it might be required to move further forward.
Sometimes we get lost in code. Sometimes we get really lost in code. This often happens when a given block is hacked together out of various parts — a template was copied from the sample, a buddy has “helped” with a part, someone has posted something on the forums… There’s a mess of a function, no one knows how exactly it came to be or what exactly it does. Such code often produces bang-your-head-against-the-wall type of bugs.
Rather than fixing a broken mess, sometimes it might be simpler to start from scratch. Unusable lines of code don’t bring one any closer to the solution, so removing them should not be taken with difficulty. It’s a tradeoff in effort between understanding faulty code well enough to fix the problem, and writing your own code (which you presumably understand since you wrote it yourself). Of course this works better when there is less code to rewrite, so a reasonable effort should be put into narrowing down the location of the bug.
It happens that my own code is at fault. It might be a sign that I didn’t allow for enough thought before beginning to type. So instead of getting frustrated with an elusive flaw — sometimes a block of code gets scrapped. Now, having thought more about the problem and having experienced the associated pitfalls, while writing and fixing the previous attempt, it’s often easier to come up with a new, more elegant, solution.
In programming, it is important to understand your instructions. Lines of code that hinder this understanding should be removed.
Read more
Discussion
Post a comment
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Just make sure you’ve got a complete set of unit tests for the code you’re deleting. Otherwise, if you’re scrapping real, production code, you’re likely deleting years of bug fixing along with the one bug you need to deal with.
Reply to comment
Here’s an example of when it’s better just to delete code than to try and debug it:
I was writing an algorithm for finding the shortest path through a bunch of airport stops. It was two days before it was due and it was around 3am. I basically just spit out a tonne of code, and then fell asleep.
The next morning I came back to my code and tried to get it to work. After two hours and looking through the horribly coded algorithm I decided to delete it and try again. It took me one hour to write the new algorithm. It worked, was more efficient and was about half of the code.
It probably would have taken me another at least 5 hours to re-write the previously poorly coded algorithm instead of the one hour it took me to write a new one.
The moral of this story is 1) Delete your code if it’s more efficient just to re-write it and 2) Don’t code at 3am
Reply to comment
rewrites only work if it’s your second time solving the problem
rewriting someone else’s broken code means your also leaving out what might potentially be code to handle a dozen corner cases you haven’t thought of because it’s your first time solving the problem.
Reply to comment
Of course this only apply to your own code or for a code where you have a really good knowledge of the entire code involved.
Or sometime, you have some function that doesn’t interfere to much with the other code (get some params, return some others).
I had this recently too, I was falling asleep on some complex function made from various version I did before, I rewrote all from scratch the next morning in a much more efficient way.
Reply to comment
One minor point that makes the deleting less painful. Save your program as a new version and delete the buggy code in the new version. Although you will almost never go back to the old version it is comforting to know that you can. Commenting out the buggy mess is OK too, but I find the clutter can distract you.
Reply to comment
McKenzie, that is what Source Code Control is for!
I agree with your comment about Clutter. As Steve McConnell said in “Code Complete”: If the comment and code disagree, then they are both probbaly wrong!
Reply to comment
Heh, have had to do this a couple of times on practice programs.
I find that McKensie solution works well for me though, as I have never liked to have any options cut off from me.
But I find that if something confuses me, leave for a day or two, do other stuff (game on supcomm for example) and come back later. and it all makes sense.
Now that I’ve heard about it, seems that the teddy bear sitting in the hallway will get some attention now
.
Reply to comment
My prof for Data Structures this year basically said the same thing. People seem to think that if they shorten the number of keys they press, they are doing less work. However, often times it’s faster and takes less thought to just rewrite the broken code. The only thing I’d recommend is to make a backup of your broken code “just in case”. If it’s an assignment being done at the last minute, sometimes handing in code that has a couple of bugs is better than handing in no code, or code that doesn’t compile.
(Of course, for the real world….)
Reply to comment
Theres some good tips in there.
I’m a semi pro web developer, and I find that just getting up, walking away and coming back after relaxing really helps. Its like looking at your code with news eyes, and you’d be suprised how easy it is to spot silly mistakes. I code PHP and find that dreamweaver can sometimes help debugging, if not, just get a friend to check over it
Keep up the good work on the site too
Reply to comment