Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy. This forum is not for asking programming related questions.
Just curious as to who else programs in runtime debugging into their code. I put a flag in each of my classes for debugging on/off, and if it's on, each action prints out a debug statement so I can trace where an error occurred.
I don't plan on keeping it in there at release, but for now it helps tremendously as I code and then test pieces to make sure they do what they're supposed to.
I suppose, but it's easier for me to code smaller debug chunks as I'm coding the class instead of coding the class and then writing test cases for later.
I do debugs like that, but I only do it with a few test cases and if everything works as expected, I let it be. I wouldn't take the time to program a debugging mode into them, though.
I might add in some debugging stuff in dev, but only to test special cases of things not working from production. I never leave it in if I can avoid it, and I try not to put too much debugging in if I can avoid that as well.
I think the only time I do anything like this is in things like parsers where there are many different error conditions. But in that case I only set an error number that can used to determine where there might be problems with the input data or configuration, for example.
I suppose, but it's easier for me to code smaller debug chunks as I'm coding the class instead of coding the class and then writing test cases for later.
Is that what Test Driven Development is for? (with unit testing)
TheMoose wrote:I suppose, but it's easier for me to code smaller debug chunks as I'm coding the class instead of coding the class and then writing test cases for later.
You're meant to write the tests before you write the class.
As it happens I do write debugging stuff into my code, but it doesn't print anything. It sends a debug message to an error handling class. The error handler can do all sorts, printing to the screen, logging to a file, logging to a database, etc. That enables me to add auditing to a site that can run for a few days to pick up on bits that are slow, or find bugs that my test cases haven't picked up (which happens more often than it ought to ).