[Singulaire]

How do you guys keep your cool and not lose your sanity while you're debugging your code? It seems I spiral further and further down every time I fix a bug in my code only for it to introduce in some random and extraneous bug and it turns into a perverse game of whack-a-mole. Thankfully though, it seems my sanity has disappeared long ago so I suppose I don't have to worry about losing it while debugging.

[szofovol]

Just take it one step at a time and take breaks. But the best way to solve a bug is to not make it in the first place, I often just make a skeleton of functions or flow graph of how they interact so I know my end goal when I start

[yueiinakano]

listening to calming music helps a lot

[riqboy]

to add to this. Its just a grind man. You. do bad until you git gud. Understanding of models and concepts stop you from making big structural mistakes.... IDE's stop you from making silly mistakes. I take breaks and seperate my projects approriately so one mistake doesnt destroy the entire thing. Make sure you understand how every thing works before you move on. So you know it works every time and not some of the time.

[descypiro]

What I am going to tell isn't so much a solution right now. Is more of a solution on the long term, but... here we go:
— Use TDD (Test Driven Development).

1. You will debug less (because there will be less bugs).
2. If you find a bug, then:
— Write the test for the behaviour that is failing.
— Run the tests and watch it go red, since the behaviour fails.
— Do a change to fix the bug.
— Run the tests, and it will go green if it's solved. Other way, continue doing changes and running the tests until everything goes green.
3. If while fixing a bug, you break any other part of the program that was already there... That part of the program will have it's own test, so the moment you run the tests you will see what you broke.
4. It isn't the same to debug by testing it manually again and again, spending minutes, than by pushing a button and watching tests go red/green. It's much faster and comfortable to have it automated with tests.


Example:
1. NO TDD
— You have a filter that takes a set of cars, filters those by type (SUV, coupe, sedan...) and gives you back the filtered cars.
— You want to add a new functionality to filter the cars by brand.
— You implement the filter by brand, you test it manually, and it works.
— You deploy it... Oh, one day later some customer is calling. Looks like the filter by car type isn't working because of some change you did.
— Time to debug and fix it. And it has already affected customers.

2. TDD
— You have a filter that takes a set of cars, filters those by type (SUV, coupe, sedan...) and gives you back the filtered cars. It was developed with TDD, so it has its own tests.
— You want to add a new functionality to filter the cars by brand.
— You implement the test to filter by brand.
— You implement the filter by brand, and run the tests. Oh, looks like the test for filter by type is broken, and it tells you how it fails.
— You do the required changes to fix it, and run the tests. Everything is green.
— You deploy it. All filters are working. Nobody's calling. Customers never noticed the bug, because you noticed and fixed it during implementation.


TDD video:

RE: Keeping Sanity while Debugging Code.

Registered Members Only

You need to be a registered member to see more on RE: Keeping Sanity while Debugging Code.
Login or Sign up to get access to a huge variety of top quality leaks.