硬件工程師的10個(gè)C語(yǔ)言技巧
當(dāng)然,現(xiàn)在仍有一些場(chǎng)合適于使用匯編語(yǔ)言,但這種場(chǎng)合仍比較少。首個(gè)推薦的場(chǎng)合是開發(fā)引導(dǎo)裝載程序。這種情況下,可能需要優(yōu)化對(duì)啟動(dòng)過程中某個(gè)決策(啟動(dòng)應(yīng)用或引導(dǎo)加載器)的速度。此時(shí),分支判定用匯編代碼就可能有意義了。另一種場(chǎng)合是開發(fā)一種在DSP上運(yùn)行有嚴(yán)格時(shí)序要求的控制循環(huán)。為了從設(shè)備中的得到每個(gè)時(shí)鐘周期,用匯編語(yǔ)言做控制循環(huán)的編碼是有意義的。如果目前任務(wù)適合用匯編,應(yīng)確保將其妥善存檔便于有據(jù)可查,這樣,未來的開發(fā)者(或未來的版本)會(huì)明白該代碼的用途。
本文引用地址:http://butianyuan.cn/article/262754.htm技巧#5:充分利用模塊化
筆者最常見的經(jīng)歷是著手由硬件工程師開啟的一個(gè)新項(xiàng)目往往是雜亂無(wú)章的代碼組織。通常我們會(huì)發(fā)現(xiàn),代碼由一個(gè)單一的主模塊組成,其中有2.5萬(wàn)多行代碼。在這些應(yīng)用中,一切都是全局性的,函數(shù)寥寥無(wú)幾,goto語(yǔ)句貫穿整個(gè)代碼結(jié)構(gòu)。15年前這算正常,但如今已不再適用了!C語(yǔ)言編程使工程師能夠?qū)⒋a分成獨(dú)立的功能模塊,這簡(jiǎn)化了代碼導(dǎo)航,同時(shí)還能夠使工程師使用封裝等面向?qū)ο蠹夹g(shù)。代碼可以被組織成邏輯模塊,這很有意義。雖然可能要先花點(diǎn)時(shí)間(幾分鐘),但從長(zhǎng)遠(yuǎn)來看,這將能省掉很多漫長(zhǎng)之夜,和很多調(diào)試之苦!
技巧#6:寫千層餅式代碼而非面條式代碼
Beningo是一個(gè)意大利名字,和許多意大利人一樣,我對(duì)意大利面食也是毫無(wú)保留地?zé)釔?。?dāng)拿意大利面食與軟件相比時(shí),我就會(huì)想到兩種面食,即意大利面條和千層餅。意大利面條比較混亂,面條相互交織,縱橫交錯(cuò),結(jié)果完全沒有任何類型的結(jié)構(gòu)。編寫非結(jié)構(gòu)化代碼就非常像意大利面條:咬一口,完全不知道吃的是哪部分。
另一種就是意大利千層餅!這種面食是分層的,是有結(jié)構(gòu)的。分層開發(fā)的代碼不僅更容易理解,還可以移走一層并添加一個(gè)新層,基本上能夠?qū)崿F(xiàn)重復(fù)使用和維護(hù)的簡(jiǎn)易性。圖1為用千層餅式代碼模型的一個(gè)簡(jiǎn)單軟件模塊示例。
圖1 千層餅軟件 模型
驅(qū)動(dòng)程序配置
應(yīng)用程序配置
應(yīng)用程序
驅(qū)動(dòng)程序庫(kù)
硬件
技巧#7:使用描述式變量名稱
編寫易于理解和維護(hù)的較大軟件有許多障礙,其中之一就是變量的命名習(xí)慣。為了盡力縮短變量名,開發(fā)者通常會(huì)自創(chuàng)一些較短的、令人費(fèi)解的助記符,往往只有他們自己才能明白的符號(hào)?,F(xiàn)代語(yǔ)言使一個(gè)變量名可以包含數(shù)百個(gè)字符。為了讓事情清晰明確,“直截了當(dāng)”地方法要好于其它方式。因此,變量名一目了然不僅有利于開發(fā)人員,也有利于未來的維護(hù)團(tuán)隊(duì)。列表8給出一個(gè)示例。
列表8 變量的命名
技巧#8:少用#pragma語(yǔ)句
C語(yǔ)言中有一種特殊的#pragma語(yǔ)句。這些語(yǔ)句通常處理非標(biāo)準(zhǔn)的句法和特性,應(yīng)盡可能避免使用這種語(yǔ)句,因?yàn)樗鼈兪欠菢?biāo)準(zhǔn)的,不能從一個(gè)處理器移植到另一個(gè)處理器。有些編譯器可能要求用這類語(yǔ)句完成某項(xiàng)任務(wù),例如定義一個(gè)中斷服務(wù)程序。在這種情況下,可能除了使用#pragma語(yǔ)句以外別無(wú)它法。如果可能,將所有的#pragma語(yǔ)句放在一個(gè)模塊或幾個(gè)模塊里。這有助于確保在代碼移植時(shí),只需要更新幾處代碼,而非整個(gè)代碼庫(kù);此外,這也將有助于防止移植代碼的首次編譯所帶來的困擾。
技巧#9:錯(cuò)誤往往并不是看上去那樣簡(jiǎn)單
在調(diào)試一個(gè)C程序時(shí),有一個(gè)讓人當(dāng)心的陷阱就是編譯器錯(cuò)誤。由于編譯器的復(fù)雜性,當(dāng)檢測(cè)到一個(gè)錯(cuò)誤時(shí),通常錯(cuò)誤位于程序中的其它地方,而非編譯器所指示的位置。這主要與編譯器生成程序的步驟有關(guān)。錯(cuò)誤類型通常是一致的,工程師可以發(fā)現(xiàn)的一些錯(cuò)誤中,90%都是根源:
*當(dāng)心漏掉#include文件。這可能會(huì)使程序開發(fā)人員看到完美的代碼行,但由于未包含必要的頭文件,編譯器便會(huì)將其標(biāo)志為一個(gè)錯(cuò)誤,表示有些東西未定義。
*當(dāng)心漏掉分號(hào)。編寫C代碼時(shí)最常見的錯(cuò)誤是忘記在句末加分號(hào)。
*當(dāng)心漏掉括號(hào)。漏寫括號(hào)是代碼編寫過程中又一常犯的錯(cuò)誤,或是粗心漏掉,或是由于鍵入錯(cuò)誤而產(chǎn)生一個(gè)錯(cuò)誤字符。
*當(dāng)心漏掉逗號(hào)。在復(fù)雜的定義中很容易忘記逗號(hào)!
一般情況下,當(dāng)彈出一個(gè)奇怪的編譯錯(cuò)誤對(duì)話框時(shí),要查看該行前已被編譯的內(nèi)容。很有可能就是錯(cuò)誤所在!它可能是出現(xiàn)在一行上面,或中間部分,或在完全不同的文件里。
不要放棄!只要具備一定的經(jīng)驗(yàn),解決這些疑難問題就會(huì)成為一種第二天性。
技巧#10:優(yōu)秀的程序員編寫的代碼行數(shù)不一定少
人們常有這種誤解,即認(rèn)為較一般的程序員而言,一個(gè)優(yōu)秀的程序員往往寫較少的代碼行就能解決問題。不要卷入這一錯(cuò)誤的想法!一個(gè)優(yōu)秀的程序員通常具備思維縝密、結(jié)構(gòu)清晰的編碼基礎(chǔ)。變量命名和封裝都恰如其分,系統(tǒng)中幾乎不用全局變量。函數(shù)應(yīng)保持簡(jiǎn)短有效。如果代碼看起來很混亂,需要多寫幾行才能使其看上去更清晰,那就不妨多寫幾行!可以上網(wǎng)查看獲得C代碼編寫最混亂殊榮獎(jiǎng)項(xiàng)的代碼用作前車之鑒。優(yōu)秀程序員寫的代碼簡(jiǎn)潔、易于理解和維護(hù),代碼行數(shù)并非最少(圖2)!
圖2 簡(jiǎn)短程序
作者簡(jiǎn)介
Jacob Beningo獲得了軟件工程職業(yè)認(rèn)證(CSDP),專業(yè)從事高質(zhì)量、穩(wěn)健的嵌入式系統(tǒng)的開發(fā)和設(shè)計(jì)。他著有許多關(guān)于嵌入式設(shè)計(jì)方法的科技論文,并教授有關(guān)可編程的設(shè)備、引導(dǎo)加載程序和軟件方法等課程。Beningo獲得了中密歇根大學(xué)(簡(jiǎn)稱CMU)(密歇根州歡喜山校區(qū))工程物理學(xué)學(xué)士學(xué)位,以及密歇根大學(xué)(密歇根州安娜堡分校)空間系統(tǒng)工程碩士學(xué)位。
c語(yǔ)言相關(guān)文章:c語(yǔ)言教程
c++相關(guān)文章:c++教程
衰減器相關(guān)文章:衰減器原理
評(píng)論