Avoiding messiness with debug stuff in code - iphone

Question

When I write something, half the effort tends to go into adding clear and concise debug output, or functionality that can be enabled/disabled when that something needs debugging.
An example of debug functionality is a downloader class where I can turn on a #define which makes it "pretend" to download the file and simply hand me back the one I have already. That way I can test to see what happens when a user downloads a file, without having to wait for the network to physically grab the file every single time. This is great functionality to have, but the code gets messier with the #ifdefs.
I eventually end up with a bunch of #defines like
// #define DEBUG_FOOMODULE_FOO
// #define DEBUG_BARMODULE_THINGAMAJIG
// ...
which are uncommented for the stuff I want to look at. The code itself turns out something like
- (void)something
{
#ifdef DEBUG_FOOMODULE_FOO
DebugLog(#"something [x = %#]", x);
#endif
// ...
#ifdef DEBUG_FOOMODULE_MOO
// etc
}
This works great for writing / maintaining the code, but it does nothing for the appearance of the code.
How do people write effortless on-the-fly long-term debug "stuff" anyway?
Note: I'm not only talking about NSLogging here... I'm also talking about stuff like the pretend-download above.

Answer 1

I read several libraries before writing my own and saw two approaches: macro + C functions (NSLogger) or macro + Singleton (GTMLogger, Cocoa Lumberjack).
I wrote my naive implementation here using macro + singleton. I do this during runtime:
[Logger singleton].logThreshold = kDebug;
trace(#"hi %#",#"world); // won't show
debug(#"hi %#",#"world);
You could do the same for packages instead log levels. If I want it gone, I change the #defines. Here is the code involved:
#define trace(args...) [[Logger singleton] debugWithLevel:kTrace line:__LINE__ funcName:__PRETTY_FUNCTION__ message:args];
if (level>=logThreshold){
// ...
}
If you want something more sophisticated look into Lumberjack, it has a register class facility to toggle logging for some classes.

Answer 2

Having two functions and then select them appropriately either at run-time or when compiling seems like a clean approach to me. This makes it possible to have one download.c and one download_debug.c file with the same functions except with different implementations. Then link with the appropriate one if you are building with -DDEBUG or not.
Otherwise, using function pointers works as well for run-time selecting functions.
If you insist of having debug code interspersed throughout your functions, you are pretty much setting up yourself for a mess :) But, you can of course break out those snippets into separate functions and then do the above (or make them no-ops as in the DLog example).

Answer 3

For your case, you could have separate logging macros, say MooLog and FooLog, that all conditionally compile based upon separate flags.
#ifdef DEBUG_FOO
# define FooLog(fmt, ...) NSLog((#"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
#else
# define FooLog(...)
#endif
#ifdef DEBUG_MOO
# define MooLog(fmt, ...) NSLog((#"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
#else
# define MooLog(...)
#endif
Your complex logic everywhere now becomes this:
- (void)something
{
// This only gets logged if the "DEBUG_FOO" flag is set.
FooLog(#"something [x = %#]", x);
// This only gets logged if the "DEBUG_MOO" flag is set.
MooLog(#"Something else [y = %#]", y);
}