Quote: "That debug file is pretty advanced it looks like"
After you have that written (considering it has already been written in C, it should be pretty much portable) you can reuse it all over the place. Like so:
int DoDivide(int numerator, int denominator) {
int division;
DebugLog("numerator=%i, denominator=%i\n", numerator, denominator);
division = numerator/denominator;
DebugLog("division=%i\n", division);
return division;
}
Likewise, my point for using assert allows you to not only clarify what types of input your code expects, but also to verify that invalid input is not passed through. Let's take another look at that DoDivide() sample:
int DoDivide(int numerator, int denominator) {
int division;
DebugLog("numerator=%i, denominator=%i\n", numerator, denominator);
assert(denominator != 0); //can't divide by zero!
division = numerator/denominator;
DebugLog("division=%i\n", division);
return division;
}
That sort of regulation (assert) makes it easier to maintain code for (1) people who have just laid their eyes on it, like team mates, (2) yourself after you haven't seen it in a while, (3) yourself while debugging. Likewise, if a client says "it crashed!" the debug log helps, but so does the assert message because it can tell you exactly which file/line tripped the assert. (Custom-defining assert allows you to take advantage of this.) In GCC, Clang, Intel C/C++ and Microsoft Visual C++ you can also access the name of the function as well. If you were dedicated enough, you can even go through the process of performing a stack trace so you could see which functions called which other functions with which parameters prior to crashing. (However, this is a more advanced topic... But there should be libraries available for this.)
Edit: Also, there's more to KISS (I find) than in just programming. If you make it easy for yourself to manage in the future, it's worth the "suffering" you have to go through today. Imagine you've written a piece of software that thousands of people run. Would you rather interact directly with those people trying to figure out what the error is or how they got it (keep in mind, most people don't understand the type of information you need) or would you rather just have the information? All of the above suggestions help you produce more stable software, which should be your number one priority.
