C语言函数的参数检查

C语言中对函数进行参数检查能够保证软件的健壮性，同时也必然会带来程序性能的降低。这让我在一段时间内常常为是否应该执行参数检查而纠结不已。

先来谈谈参数检查的方法。我知道的参数检查方法有两种：一种是通过条件判断语句，如下：

int foo(char *p)
{
    if (p == NULL)
    {
        return -1;
    }

    // do something
}

实际使用时，从效率角度出发，程序员往往会在参数检查语句外面加一个宏开关，再把所有宏开关的定义统一放在形如config.h的配置文件中，如下所示：

config.h:

#define MOD_CHK_PARAM    (1)    // 0 - 关闭宏，1 - 打开宏

app.c:

[c title="app.c"]
int foo(char *p)
{
#if MOD_CHK_PARAM > 0
    if (p == NULL)
    {
        return -1;
    }
#endif

    // do somethhing
}

这种方法的好处是，代码的使用者能灵活的配置各项参数检查的开关。但这种方法带来的问题是使用者总是得通过函数的返回值来判断哪个参数在传递时出了问题，而且往往无法直接判断（不同的参数错误有时会返回同一个错误值，比如-1）。

参数检查的另外一种方法是通过C语言标准库提供的断言（assert）机制（断言的原理比较简单，以至于用户可以自己实现），使用方法如下：

#include <assert.h>

int foo(char *p)
{
    assert(p != NULL);

    // do something
}

用断言的好处是能直观的反应出错误在哪，缺点是没那么灵活，因为断言要么开，要么关，不存在关一部分断言的情况。想关闭断言，只要在#include <assert.h>之前定义一个NDEBUG宏即可，如下：

#define NDEBUG
#include <assert.h>

回到日常编码时是否要添加参数检查的问题，我的答案是，要添加参数检查代码。至于添加的方式，如果代码本身是面向程序员的话（比如uCOS-II、uCOS-III），建议还是采用宏开关的方式，把选择权交给用户程序员。而如果代码本身最终面向的是普通老百姓的话，还是采用断言的方式，在调试阶段打开断言，调试完成后关闭断言。