|
硬件設計師最常見(jiàn)的工作內容是通過(guò)寫(xiě)代碼來(lái)測試硬件。這10個(gè)C語(yǔ)言技巧（C語(yǔ)言仍然是常見(jiàn)的選擇）可以幫助設計師避免因基礎性錯誤而導致某些缺陷的產(chǎn)生并造成維護方面的困擾。 為了成功的推出一個(gè)產(chǎn)品，軟件開(kāi)發(fā)過(guò)程本身需要經(jīng)歷無(wú)數的實(shí)踐風(fēng)險和障礙。任何工程師最不希望的事情就是因所使用語(yǔ)言或工具而帶來(lái)的挑戰。因此，這就需要硬件設計師編寫(xiě)代碼來(lái)測試硬件的工作狀況，在資源受限的情況下，還需要開(kāi)發(fā)硬件和嵌入式軟件。盡管工具和結構化編程已經(jīng)有了很大進(jìn)展，但通常選擇的仍然是C語(yǔ)言，基礎性錯誤的不斷發(fā)生，仍會(huì )導致某些缺陷的產(chǎn)生并造成維護方面的困擾。為竭力避免這些C編程陷阱，這里有10個(gè)C語(yǔ)言技巧供硬件工程師參考。 技巧#1：不要使用“GOTO”語(yǔ)句 二十幾年前，當計算機編程尚處于起步階段時(shí)，程序流程是由“GOTO”語(yǔ)句來(lái)控制。該類(lèi)語(yǔ)句允許程序員對當前代碼行斷行，而直接進(jìn)入另一個(gè)不同的代碼段。列表1為簡(jiǎn)單的示例。 列表1 使用GOTO語(yǔ)句 編程語(yǔ)言終究開(kāi)始引入了函數的概念，即允許程序對代碼進(jìn)行斷行。如果已經(jīng)完成，不再使用goto語(yǔ)句來(lái)表示代碼的斷行。函數調用后，函數將回到下一條指令。列表2為示例。這一做法改善了程序結構，提高了可讀性。自此，這被視為編寫(xiě)程序的正確方法。只要看到或想到goto語(yǔ)句,就會(huì )讓軟件工程師退縮，產(chǎn)生本能的厭惡。其中一個(gè)主要的原因是，一個(gè)遍布goto語(yǔ)句的程序會(huì )讓讓人很難抓住重心，不便于對程序的理解和維護。 列表2 用函數控制流程 技巧#2：使用FOR（；；）或While（1） 如果goto語(yǔ)句已經(jīng)過(guò)時(shí)，那么對程序創(chuàng )建無(wú)限循環(huán)應該如何去做呢，這是一些硬件工程師可能會(huì )疑惑的問(wèn)題。畢竟，之前都是通過(guò)創(chuàng )建一個(gè)goto語(yǔ)句然后再返回到main語(yǔ)句。解決這一問(wèn)題就要利用C語(yǔ)言中已經(jīng)存在的循環(huán)語(yǔ)句for和while（列表3和4）。 列表3 使用一個(gè)無(wú)限的For循環(huán) 列表4 使用一個(gè)無(wú)限的While循環(huán) 列表中的循環(huán)條件相對比較簡(jiǎn)單。for循環(huán)無(wú)非是以無(wú)條件情況使用條件語(yǔ)句。而另一方面，while循環(huán)是語(yǔ)句為真即予執行，這等同對任何條件的非零值。 技巧#3：使用合適的條件語(yǔ)句 除代碼的可讀性之外，程序的執行時(shí)間還主要依賴(lài)于做決定時(shí)所選擇的條件結構類(lèi)型。許多硬件工程師都熟悉簡(jiǎn)單的if語(yǔ)句的使用。然而，有時(shí)工程師可能沒(méi)有意識到，如果第一個(gè)條件不正確，還可以使用else或else if語(yǔ)句。這可以節省處理器時(shí)間，而不必評估另一個(gè)條件語(yǔ)句。在列表5所示的前半部分代碼中，如果Var值為1，則代碼仍會(huì )查看Var是否為0。而在用了else語(yǔ)句的后半部分代碼中，只評估第一個(gè)語(yǔ)句，之后就繼續走下面的代碼，這樣就節省了時(shí)鐘周期，使代碼更加清晰。 列表5 用If/Else替代只用If If/else if/else語(yǔ)句可能并不永遠適用。如果需要檢查若干個(gè)可能的條件，switch語(yǔ)句可能更合適。這樣,處理器可以評估語(yǔ)句，然后從一個(gè)答案列表中選擇下一步動(dòng)作，而不用連續地評估一堆條件。列表6顯示的例子與列表5示例的類(lèi)型相同。 列表6 使用Switch語(yǔ)句 以上示例的寓意是，讓條件語(yǔ)句的選擇更開(kāi)放，以選擇出最適合的語(yǔ)句。這種做法使程序結構更簡(jiǎn)單，便于理解程序流程，縮短處理器的額外時(shí)鐘周期。 技巧#4：避免使用匯編語(yǔ)言 微處理器的自然語(yǔ)言為匯編語(yǔ)言指令。為低級別機器語(yǔ)言編程可能會(huì )為處理器提供更高效的代碼。然而，人類(lèi)并不是天生就會(huì )這種語(yǔ)言，并且經(jīng)驗表明，編寫(xiě)匯編語(yǔ)言會(huì )造成誤解。誤解會(huì )導致維護不當，更甚者，可能會(huì )使系統到處是bug。一般建議避免使用匯編語(yǔ)言。實(shí)際上，現在大多數編譯器都能編譯出非常高效的代碼。采用C語(yǔ)言或C++語(yǔ)言等高級語(yǔ)言的開(kāi)發(fā)，能獲得更有序的結構，便于理解和維護，使代碼的整體效果更好。列表7給出了一個(gè)示例，比較了使一個(gè)32位變量遞增所使用的匯編代碼和C語(yǔ)言代碼。 列表7 用匯編和C語(yǔ)言完成一個(gè)變量的遞增 匯編 C代碼 當然，現在仍有一些場(chǎng)合適于使用匯編語(yǔ)言，但這種場(chǎng)合仍比較少。首個(gè)推薦的場(chǎng)合是開(kāi)發(fā)引導裝載程序。這種情況下，可能需要優(yōu)化對啟動(dòng)過(guò)程中某個(gè)決策（啟動(dòng)應用或引導加載器）的速度。此時(shí)，分支判定用匯編代碼就可能有意義了。另一種場(chǎng)合是開(kāi)發(fā)一種在DSP上運行有嚴格時(shí)序要求的控制循環(huán)。為了從設備中的得到每個(gè)時(shí)鐘周期，用匯編語(yǔ)言做控制循環(huán)的編碼是有意義的。如果目前任務(wù)適合用匯編，應確保將其妥善存檔便于有據可查，這樣，未來(lái)的開(kāi)發(fā)者（或未來(lái)的版本）會(huì )明白該代碼的用途。 技巧#5：充分利用模塊化 筆者最常見(jiàn)的經(jīng)歷是著(zhù)手由硬件工程師開(kāi)啟的一個(gè)新項目往往是雜亂無(wú)章的代碼組織。通常我們會(huì )發(fā)現，代碼由一個(gè)單一的主模塊組成，其中有2.5萬(wàn)多行代碼。在這些應用中，一切都是全局性的，函數寥寥無(wú)幾，goto語(yǔ)句貫穿整個(gè)代碼結構。15年前這算正常，但如今已不再適用了！C語(yǔ)言編程使工程師能夠將代碼分成獨立的功能模塊，這簡(jiǎn)化了代碼導航，同時(shí)還能夠使工程師使用封裝等面向對象技術(shù)。代碼可以被組織成邏輯模塊，這很有意義。雖然可能要先花點(diǎn)時(shí)間（幾分鐘），但從長(cháng)遠來(lái)看，這將能省掉很多漫長(cháng)之夜，和很多調試之苦！ 技巧#6：寫(xiě)千層餅式代碼而非面條式代碼 Beningo是一個(gè)意大利名字，和許多意大利人一樣，我對意大利面食也是毫無(wú)保留地熱愛(ài)。當拿意大利面食與軟件相比時(shí)，我就會(huì )想到兩種面食，即意大利面條和千層餅。意大利面條比較混亂，面條相互交織，縱橫交錯，結果完全沒(méi)有任何類(lèi)型的結構。編寫(xiě)非結構化代碼就非常像意大利面條：咬一口，完全不知道吃的是哪部分。 另一種就是意大利千層餅！這種面食是分層的，是有結構的。分層開(kāi)發(fā)的代碼不僅更容易理解，還可以移走一層并添加一個(gè)新層，基本上能夠實(shí)現重復使用和維護的簡(jiǎn)易性。圖1為用千層餅式代碼模型的一個(gè)簡(jiǎn)單軟件模塊示例。 圖1 千層餅軟件模型 驅動(dòng)程序配置 應用程序配置 應用程序 驅動(dòng)程序庫 硬件 技巧#7:使用描述式變量名稱(chēng) 編寫(xiě)易于理解和維護的較大軟件有許多障礙，其中之一就是變量的命名習慣。為了盡力縮短變量名，開(kāi)發(fā)者通常會(huì )自創(chuàng )一些較短的、令人費解的助記符，往往只有他們自己才能明白的符號�，F代語(yǔ)言使一個(gè)變量名可以包含數百個(gè)字符。為了讓事情清晰明確，“直截了當”地方法要好于其它方式。因此，變量名一目了然不僅有利于開(kāi)發(fā)人員，也有利于未來(lái)的維護團隊。列表8給出一個(gè)示例。 列表8 變量的命名 技巧#8:少用＃pragma語(yǔ)句 C語(yǔ)言中有一種特殊的＃pragma語(yǔ)句。這些語(yǔ)句通常處理非標準的句法和特性，應盡可能避免使用這種語(yǔ)句，因為它們是非標準的，不能從一個(gè)處理器移植到另一個(gè)處理器。有些編譯器可能要求用這類(lèi)語(yǔ)句完成某項任務(wù)，例如定義一個(gè)中斷服務(wù)程序。在這種情況下，可能除了使用＃pragma語(yǔ)句以外別無(wú)它法。如果可能，將所有的＃pragma語(yǔ)句放在一個(gè)模塊或幾個(gè)模塊里。這有助于確保在代碼移植時(shí)，只需要更新幾處代碼，而非整個(gè)代碼庫；此外，這也將有助于防止移植代碼的首次編譯所帶來(lái)的困擾。 技巧#9:錯誤往往并不是看上去那樣簡(jiǎn)單 在調試一個(gè)C程序時(shí)，有一個(gè)讓人當心的陷阱就是編譯器錯誤。由于編譯器的復雜性，當檢測到一個(gè)錯誤時(shí)，通常錯誤位于程序中的其它地方，而非編譯器所指示的位置。這主要與編譯器生成程序的步驟有關(guān)。錯誤類(lèi)型通常是一致的，工程師可以發(fā)現的一些錯誤中，90%都是根源： ?當心漏掉＃include文件。這可能會(huì )使程序開(kāi)發(fā)人員看到完美的代碼行，但由于未包含必要的頭文件，編譯器便會(huì )將其標志為一個(gè)錯誤，表示有些東西未定義。 ?當心漏掉分號。編寫(xiě)C代碼時(shí)最常見(jiàn)的錯誤是忘記在句末加分號。 ?當心漏掉括號。漏寫(xiě)括號是代碼編寫(xiě)過(guò)程中又一常犯的錯誤，或是粗心漏掉，或是由于鍵入錯誤而產(chǎn)生一個(gè)錯誤字符。 ?當心漏掉逗號。在復雜的定義中很容易忘記逗號！ 一般情況下，當彈出一個(gè)奇怪的編譯錯誤對話(huà)框時(shí)，要查看該行前已被編譯的內容。很有可能就是錯誤所在！它可能是出現在一行上面，或中間部分，或在完全不同的文件里。 不要放棄！只要具備一定的經(jīng)驗，解決這些疑難問(wèn)題就會(huì )成為一種第二天性。 技巧#10:優(yōu)秀的程序員編寫(xiě)的代碼行數不一定少 人們常有這種誤解，即認為較一般的程序員而言，一個(gè)優(yōu)秀的程序員往往寫(xiě)較少的代碼行就能解決問(wèn)題。不要卷入這一錯誤的想法！一個(gè)優(yōu)秀的程序員通常具備思維縝密、結構清晰的編碼基礎。變量命名和封裝都恰如其分，系統中幾乎不用全局變量。函數應保持簡(jiǎn)短有效。如果代碼看起來(lái)很混亂，需要多寫(xiě)幾行才能使其看上去更清晰，那就不妨多寫(xiě)幾行！可以上網(wǎng)查看獲得C代碼編寫(xiě)最混亂殊榮獎項的代碼用作前車(chē)之鑒。優(yōu)秀程序員寫(xiě)的代碼簡(jiǎn)潔、易于理解和維護，代碼行數并非最少（圖2）！ 圖2 簡(jiǎn)短程序 作者簡(jiǎn)介 Jacob Beningo獲得了軟件工程職業(yè)認證（CSDP），專(zhuān)業(yè)從事高質(zhì)量、穩健的嵌入式系統的開(kāi)發(fā)和設計。他著(zhù)有許多關(guān)于嵌入式設計方法的科技論文，并教授有關(guān)可編程的設備、引導加載程序和軟件方法等課程。Beningo獲得了中密歇根大學(xué)（簡(jiǎn)稱(chēng)CMU）（密歇根州歡喜山校區）工程物理學(xué)學(xué)士學(xué)位，以及密歇根大學(xué)（密歇根州安娜堡分校）空間系統工程碩士學(xué)位。 |
