I just finished programming a large project in C. I have a lot of debugging code (printfs and what not within the code). Now those debugging statements are a performance overhead and I want to remove them but they are very helpful in the future for trouble shooting purposes. What are the best practices to put the debug code in the code base. I have across many options.
Use a terminal argument (let's say -d) to specify if the executable should run in debug mode or not. The advantage is that the code will not change later. The disadvantage is that the code will be full of conditionals to check if the program is in debug mode or not
The other solution is to use some C macros for debugging. I don't quite understand how this works. It seems like you would define d_printf that would be printf if you are in debug mode and nothing if you are in not. But I guess this will requires recompiling the code every time you change from a debug mode to a non debug mode.
Can experienced C professionals advise about what the best practises are?
Personally I like the ability to turn on debug without needing a recompile to enable debug.
I normally have one debug method that checks a command line arg or environment variable and output messages <= a given priority.
e.g.
void debug(int level, char *msg)
{
if (level <= currentDebugLevel) {
printf("%s\n", msg); /* or to stderr, or to file
}
}
You can make it a varargs func so you can use the same as printf
Best practices? Don't use printf() or fprintf() to stdout or stderr redirected to a file, especially for long-lived processes. Those methods can be adequate for casual debugging, but they have serious shortcomings for long-lived processes that can produce large amounts of data.
If you use printf() or fprintf() to such fixed streams or files, you become tied to those file(s) and can't easily move the logging to another file, or you can't move the data stream at all, depending on a lot of specifics. So without restarting your process you can't move the log file as part of a log file aging process nor can you truncate or otherwise remove the file if it fills up your disk space.
And there's no need to badly reinvent the wheel. Just about every OS provides a logging capability designed to scale and to meet the requirement that a log file be separable from the process doing the logging. Unix/Linux systems provide syslog (or rsyslog under the hood), Windows system have the EventLog API. Once you learn how to use and configure those, they're a lot easier to configure, code for, and use than almost any add-on logging product.
Also, define debugging macros using the __func__, __FILE__, and __LINE__ predefined values in your debug output:
#define DEBUGLOG( level, ... ) \
do \
{ \
if ( ( level ) < currentDebugLevel ) \
{ \
debugFuncCall( ( level ), __func__, __FILE__, __LINE__, __VA_ARGS__ ); \
} \
} \
while ( 0 )
That will provide very useful debugging data for very little effort. You can define simple debug macros such as ENTER_METHOD( args...) and EXIT_METHOD( retval ) macros that at the appropriate level of debugging will allow you to trace everything your program does.