作者 | 道哥

轉(zhuǎn)自 | IOT物聯(lián)網(wǎng)小鎮(zhèn)

嵌入式軟件開發(fā)，實(shí)際項(xiàng)目通常會(huì)考慮代碼的一些安全性和健壯性，一般來說，需要添加一些“檢測”的代碼。

下面就來為大家分享一下關(guān)于if和assert的內(nèi)容。

一、前言

我們?cè)跀]代碼的時(shí)候，經(jīng)常需要對(duì)代碼的安全性進(jìn)行檢查，例如：

1. 指針是否為空？
2. 被除數(shù)是否為 0？
3. 函數(shù)調(diào)用的返回結(jié)果是否有效？

4. 打開一個(gè)文件是否成功？

對(duì)這一類的邊界條件進(jìn)行檢查的手段，一般都是使用 if 或者 assert 斷言，無論使用哪一個(gè)，都可以達(dá)到檢查的目的。那么是否就意味著：這兩者可以隨便使用，想起來哪個(gè)就用哪個(gè)？

這篇小短文我們就來掰扯掰扯：在不同的場景下，到底是應(yīng)該用 if，還是應(yīng)該使用 assert 斷言？

寫這篇文章的時(shí)候，我想起了孔乙己老先生的那個(gè)問題：茴香豆的“茴”字有幾種寫法？

似乎我們沒有必要來糾結(jié)應(yīng)該怎么選擇，因?yàn)槎寄軌驅(qū)崿F(xiàn)想要的功能。以前我也是這么想的，但是，現(xiàn)在我不這么認(rèn)為。

成為技術(shù)大牛、拿到更好的offer，也許就在這些細(xì)微之間就分出了勝負(fù)。

二、assert 斷言

剛才，我問了下旁邊的一位工作 5 年多的嵌入式開發(fā)者：if 和 assert 如何選擇？他說：assert 是干什么的？！

看來，有必要先簡單說一下 assert 斷言。

assert() 的原型是：

void assert(int expression);

1. 如果宏的參數(shù)求值結(jié)果為非零值，則不做任何操作（no action）；
2. 如果宏的參數(shù)是零值，就打印診斷消息，然后調(diào)用abort()。

例如下面的代碼：

#include int my_div(int a, int b){ assert(0 != b); return a / b;} 

1. 當(dāng) b 不為 0 時(shí)，assert 斷言什么都不做，程序往下執(zhí)行；
2. 當(dāng) b 為 0 時(shí)，assert 斷言就打印錯(cuò)誤信息，然后終止程序；

從功能上來說，assert(0 != b);與下面的代碼等價(jià)：

if (0 == b){ fprintf(stderr, "b is zero..."); abort();} 

assert 是一個(gè)宏，不是一個(gè)函數(shù)

在 assert.h 頭文件中，有如下定義：

#ifdef NDEBUG #define assert(condition) ((void)0)#else #define assert(condition) /*implementation defined*/#endif 

既然是宏定義，說明是在預(yù)處理的時(shí)候進(jìn)行宏替換。(關(guān)于宏的更多內(nèi)容，可以看一下這篇文章:提高代碼逼格的利器：宏定義-從入門到放棄)。

從上面的定義中可以看到：

1. 如果定義了宏 NDEBUG，那么 assert() 宏將不做什么動(dòng)作，也就是相當(dāng)于一條空語句：(void)0;，當(dāng)在 release 階段編譯代碼的時(shí)候，都會(huì)在編譯選項(xiàng)中(Makefile)定義這個(gè)宏。
2. 如果沒有定義宏 NDEBUG，那么 assert() 宏將會(huì)把一些檢查代碼進(jìn)行替換，我們?cè)陂_發(fā)階段執(zhí)行 debug 模式編譯時(shí)，一般都會(huì)屏蔽掉這 NDEBUG 這個(gè)宏。

三、if VS assert

還是以一個(gè)代碼片段來描述問題，以場景化來討論比較容易理解。

// brief: 把兩個(gè)短字符串拼接成一個(gè)字符串char *my_concat(char *str1, char *str2){ int len1 = strlen(str1); int len2 = strlen(str2); int len3 = len1 + len2; char *new_str = (char *)malloc(len3 + 1); memset(new_str, 0 len3 + 1); sprintf(new_str, "%s%s", str1, str2); return new_str;} 

如果一個(gè)開發(fā)人員寫出上面的代碼，一定會(huì)被領(lǐng)導(dǎo)約談的！它存在下面這些問題：

1. 沒有對(duì)輸入?yún)?shù)進(jìn)行有效性檢查；
2. 沒有對(duì) malloc 的結(jié)果進(jìn)行檢查；
3. sprintf 的效率很低；
4. ...

1. 使用 if 語句來檢查

char *my_concat(char *str1, char *str2){ if (!str1 || !str2) // 參數(shù)錯(cuò)誤 return NULL;  int len1 = strlen(str1); int len2 = strlen(str2); int len3 = len1 + len2; char *new_str = (char *)malloc(len3 + 1);  if (!new_str) // 申請(qǐng)堆空間失敗 return NULL;  memset(new_str, 0 len3 + 1); sprintf(new_str, "%s%s", str1, str2); return new_str;} 

2. 使用 assert 斷言來檢查

char *my_concat(char *str1, char *str2){ // 確保參數(shù)正確 assert(NULL != str1); assert(NULL != str2);  int len1 = strlen(str1); int len2 = strlen(str2); int len3 = len1 + len2; char *new_str = (char *)malloc(len3 + 1);  // 確保申請(qǐng)堆空間成功 assert(NULL != new_str);  memset(new_str, 0 len3 + 1); sprintf(new_str, "%s%s", str1, str2); return new_str;} 

3. 你喜歡哪一個(gè)？

首先聲明一點(diǎn)：以上這 2 種檢查方式，在實(shí)際的代碼中都很常見，從功能上來說似乎也沒有什么影響。因此，沒有嚴(yán)格的錯(cuò)與對(duì)之分，很多都是依賴于每個(gè)人的偏好習(xí)慣不同而已。

（1） assert 支持者

我作為my_concat()函數(shù)的實(shí)現(xiàn)者，目的是拼接字符串，那么傳入的參數(shù)必須是合法有效的，調(diào)用者需要負(fù)責(zé)這件事。如果傳入的參數(shù)無效，我會(huì)表示十分的驚訝！怎么辦：崩潰給你看！

（2）if 支持者

我寫的my_concat()函數(shù)十分的健壯，我就預(yù)料到調(diào)用者會(huì)亂搞，故意的傳入一些無效參數(shù)，來測試我的編碼水平。沒事，來吧，我可以處理任何情況！

這兩個(gè)派別的理由似乎都很充足！那究竟該如何選擇？難道真的的跟著感覺走嗎？

假設(shè)我們嚴(yán)格按照常規(guī)的流程去開發(fā)一個(gè)項(xiàng)目：

1. 在開發(fā)階段，編譯選項(xiàng)中不定義 NDEBUG 這個(gè)宏，那么 assert 就發(fā)揮作用；
2. 項(xiàng)目發(fā)布時(shí)，編譯選項(xiàng)中定義了 NDEBUG 換個(gè)宏，那么 assert 就相當(dāng)于空語句；

也就是說，只有在 debug 開發(fā)階段，用 assert 斷言才能夠正確的檢查到參數(shù)無效。而到了 release 階段，assert 不起作用，如果調(diào)用者傳遞了無效參數(shù)，那么程序只有崩潰的命運(yùn)了。

這說明什么問題？是代碼中存在 bug？還是代碼寫的不夠健壯？

從我個(gè)人的理解上看，這壓根就是單元測試沒有寫好，沒有測出來參數(shù)無效的這個(gè) case！

4. assert 的本質(zhì)

assert 就是為了驗(yàn)證有效性，它最大作用就是：在開發(fā)階段，讓我們的程序盡可能地 crash。每一次的 crash，都意味著代碼中存在著 bug，需要我們?nèi)バ拚?/span>

當(dāng)我們寫下一個(gè) assert 斷言的時(shí)候，就說明：斷言失敗的這種情況是不可以的，是不被允許的。必須保證斷言成功，程序才能繼續(xù)往下執(zhí)行。

5. if-else 的本質(zhì)

if-else 語句用于邏輯處理，它是為了處理各種可能出現(xiàn)的情況。就是說：每一個(gè)分支都是合理的，是允許出現(xiàn)的，我們都要對(duì)這些分支進(jìn)行處理。

6. 我喜歡的版本

char *my_concat(char *str1, char *str2){ // 參數(shù)必須有效 assert(NULL != str1); assert(NULL != str2);  int len1 = strlen(str1); int len2 = strlen(str2); int len3 = len1 + len2; char *new_str = (char *)malloc(len3 + 1);  // 申請(qǐng)堆空間失敗的情況，是可能的，是允許出現(xiàn)的情況。 if (!new_str) return NULL;  memset(new_str, 0 len3 + 1); sprintf(new_str, "%s%s", str1, str2); return new_str;}

對(duì)于參數(shù)而言：我認(rèn)為傳入的參數(shù)必須是有效的，如果出現(xiàn)了無效參數(shù)，說明代碼中存在 bug，不允許出現(xiàn)這樣的情況，必須解決掉。

對(duì)于資源分配結(jié)果(malloc 函數(shù))而言：我認(rèn)為資源分配失敗是合理的，是有可能的，是允許出現(xiàn)的，而且我也對(duì)這個(gè)情況進(jìn)行了處理。

當(dāng)然了，并不是說對(duì)參數(shù)檢查就要使用 assert，主要是根據(jù)不同的場景、語義來判斷。例如下面的這個(gè)例子：

int g_state;void get_error_str(bool flag){ if (TRUE == flag) { g_state = 1; assert(1 == g_state); // 確保賦值成功 } else { g_state = 0; assert(0 == g_state); // 確保賦值成功 }} 

flag 參數(shù)代表不同的分支情況，而賦值給 g_state 之后，必須保證賦值結(jié)果的正確性，因此使用 assert 斷言。

五、總結(jié)

這篇文章分析了 C 語言中比較晦澀、模糊的一個(gè)概念，似乎有點(diǎn)虛無縹緲，但是的確又需要我們停下來仔細(xì)考慮一下。

如果有些場景，實(shí)在拿捏不好，我就會(huì)問自己一個(gè)問題：

這種情況是否被允許出現(xiàn)？

不允許：就用 assert 斷言，在開發(fā)階段就盡量找出所有的錯(cuò)誤情況；

允許：就用 if-else，說明這是一個(gè)合理的邏輯，需要進(jìn)行下一步處理。