避免代码中调试内容混乱

Question

当我编写某些内容时，一半的精力往往会花在添加清晰简洁的调试输出，或者在需要调试时可以启用/禁用的功能。

调试功能的一个示例是一个下载器类，我可以在其中打开#define，使其“假装”下载文件，然后简单地将已有的文件交还给我。这样我就可以测试用户下载文件时会发生什么，而不必每次都等待网络物理抓取文件。这是一个很棒的功能，但是使用 #ifdefs 会使代码变得更加混乱。

我最终得到了一堆像这样的#define，

// #define DEBUG_FOOMODULE_FOO
// #define DEBUG_BARMODULE_THINGAMAJIG
// ...

对于我想看的东西没有注释。代码本身看起来像这样，

- (void)something
{
    #ifdef DEBUG_FOOMODULE_FOO
    DebugLog(@"something [x = %@]", x);
    #endif
    // ...
    #ifdef DEBUG_FOOMODULE_MOO
    // etc
}

这对于编写/维护代码非常有用，但对于代码的外观没有任何作用。

人们如何轻松地编写长期调试“东西”？

注意：我在这里不仅谈论 NSLogging...我还谈论上面的假装下载之类的东西。

Answer 1

在编写自己的库之前，我阅读了几个库，并看到了两种方法：宏 + C 函数 (NSLogger) 或宏 + Singleton (GTMLogger，Cocoa Lumberjack）。

我编写了我的幼稚实现 这里使用宏+单例。我在运行时执行此操作：

[Logger singleton].logThreshold = kDebug;
trace(@"hi %@",@"world); // won't show
debug(@"hi %@",@"world);

您可以对包而不是日志级别执行相同的操作。如果我想让它消失，我会更改#defines。以下是涉及的代码：

#define trace(args...) [[Logger singleton] debugWithLevel:kTrace line:__LINE__ funcName:__PRETTY_FUNCTION__ message:args];

if (level>=logThreshold){
  // ...
} 

如果您想要对 Lumberjack 进行更复杂的了解，它有一个注册类工具来切换某些类的日志记录。

Answer 2

拥有两个函数，然后在运行时或编译时适当地选择它们对我来说似乎是一种干净的方法。这样就可以拥有一个 download.c 和一个 download_debug.c 文件，其功能相同，但实现不同。如果您是否使用 -DDEBUG 进行构建，则链接到适当的链接。

否则，使用函数指针对于运行时选择函数也同样有效。

如果您坚持将调试代码散布在您的函数中，那么您几乎会把自己设置为一团糟:)但是，您当然可以将这些片段分解为单独的函数，然后执行上述操作（或者使它们成为无操作，如在 DLog 示例中）。

Answer 3

对于您的情况，您可以有单独的日志记录宏，例如 MooLog 和 FooLog，它们都根据单独的标志进行条件编译。

#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

你到处的复杂逻辑现在变成了这样：

- (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);
}