嵌入式系統(tǒng)開(kāi)發(fā)人員應(yīng)盡可能明確,以避免 ASSUME
綜合癥并在其系統(tǒng)中產(chǎn)生意外行為。在今天的文章中,讓我們來(lái)看看嵌入式開(kāi)發(fā)人員可以通過(guò)更明確的方式清理代碼的幾個(gè)領(lǐng)域。
顯式編程技巧 #1 – 將 extern 與公共函數(shù)一起使用
我們都知道我們不應(yīng)該使用 extern,因?yàn)樗鼤?huì)創(chuàng)建全局變量,進(jìn)而可能導(dǎo)致各種問(wèn)題。但是,實(shí)際使用 extern
的一個(gè)好地方是在創(chuàng)建公共函數(shù)時(shí)。
當(dāng)你定義一個(gè)公開(kāi)的函數(shù)時(shí),你可以使用以下命令在標(biāo)頭中創(chuàng)建聲明或原型:
void Foo(void);
它在標(biāo)題中,所以很明顯它是一個(gè)公共的外部函數(shù)。但是,我遇到過(guò)這樣的情況,你正在維護(hù)一個(gè)別人編寫(xiě)的模塊,并且在像 Bar
這樣的函數(shù)的標(biāo)頭中沒(méi)有公共 API,但它的定義如下:
void Bar(void)
{
…
}
這個(gè)函數(shù)的目的是什么? 它應(yīng)該是私有的并且前面有一個(gè)靜電嗎?它應(yīng)該是公開(kāi)的并在標(biāo)題中定義嗎?如果嵌入式開(kāi)發(fā)人員將 Bar
定義為:
extern Bar(void)
{
…
}
我們會(huì)知道它是公開(kāi)的并且在 API 中缺失,盡管有人調(diào)用它,鏈接器仍然能夠找到它。
顯式編程技巧 #2 – 將指針作為 const 傳遞給函數(shù),除非它們改變
指針是危險(xiǎn)的,如果它們?cè)趫?zhí)行過(guò)程中意外地以某種意想不到的方式遞增、遞減或修改,它們很容易導(dǎo)致災(zāi)難。我經(jīng)常會(huì)遇到如下所示的函數(shù)聲明:
void Foo(uint32_t * Param1);
這個(gè)聲明是如此含蓄,我讀了這個(gè)聲明,其目的是將一個(gè)指針傳遞給一個(gè) uint32_t,其中指針和指向的 uint32_t
內(nèi)存位置都允許更改!
這是嵌入式開(kāi)發(fā)人員的本意嗎? 如果他們只是想傳遞一個(gè)指向變量的指針,以便它通過(guò)引用傳遞并且可以被函數(shù)修改怎么辦?
這個(gè)函數(shù)可以做到這一點(diǎn),但他們也打開(kāi)了修改指針的選項(xiàng)!
下面的陳述對(duì)我來(lái)說(shuō)非常清楚,指針不會(huì)改變,指向的值可以改變:
void Foo(uint32_t * const Param1);
參數(shù)是指向 uint32_t 內(nèi)存位置的 const
指針。指針在函數(shù)中不能改變,但指向的東西可以。因此,如果有人在函數(shù)中執(zhí)行以下操作:
Param++;
編譯器會(huì)說(shuō)“不! 錯(cuò)誤!”,讓維護(hù)者明白他們不應(yīng)該這樣做。
顯式編程技巧 #3 – 將“no reference”變量作為 const 傳遞
現(xiàn)在,這通常會(huì)讓嵌入式開(kāi)發(fā)人員興奮不已,而且不是很好。有人告訴我這是無(wú)稽之談,但同樣,它使包括新手在內(nèi)的任何開(kāi)發(fā)人員都清楚代碼。
這里的想法是我可能有一個(gè)聲明如下的函數(shù):
void Foo(uint32_t Param1);
在這種情況下,我通過(guò)副本而不是引用傳遞參數(shù),以供函數(shù)使用。該函數(shù)理論上可以對(duì)本地副本執(zhí)行任何操作。但同樣,如果有人在維護(hù)這段代碼,他們是否知道我們想要接收參數(shù)并將其用作常量?
對(duì)我來(lái)說(shuō),除非聲明是這樣寫(xiě)的,否則我不會(huì)有任何線索:
void Foo(const uint32_t Param1);
這告訴我,該參數(shù)預(yù)計(jì)不會(huì)在副本中更改或修改以供本地使用。
這些提示有助于使代碼更清晰,并有助于嵌入式開(kāi)發(fā)人員理解代碼的真正意圖?,F(xiàn)在,這些可能不是導(dǎo)致所有這些損失的隱式代碼的最佳做法,但它們確實(shí)讓你認(rèn)為你應(yīng)該編寫(xiě)盡可能清晰的軟件。