作為2022年的硬體工程師你還不懂這10個C語言技巧，那你就out了

技巧2：使用FOR（；；）或While（1）

如果goto語句已經過時，那麼對程序創建無限循環應該如何去做呢，這是一些硬體工程師可能會疑惑的問題。畢竟，之前都是通過創建一個goto語句然後再返回到main語句。解決這一問題就要利用C語言中已經存在的循環語句for和while（列表3和4）。

列表3使用一個無限的For循環

列表4使用一個無限的While循環

列表中的循環條件相對比較簡單。for循環無非是以無條件情況使用條件語句。而另一方面，while循環是語句為真即予執行，這等同對任何條件的非零值。

技巧3：使用合適的條件語句

除代碼的可讀性之外，程序的執行時間還主要依賴於做決定時所選擇的條件結構類型。許多硬體工程師都熟悉簡單的if語句的使用。然而，有時工程師可能沒有意識到，如果第一個條件不正確，還可以使用else或else if語句。這可以節省處理器時間，而不必評估另一個條件語句。在列表5所示的前半部分代碼中，如果Var值為1，則代碼仍會查看Var是否為0。而在用了else語句的後半部分代碼中，只評估第一個語句，之後就繼續走下面的代碼，這樣就節省了時鐘周期，使代碼更加清晰。

列表5用If/Else替代只用If

If/else if/else語句可能並不永遠適用。如果需要檢查若干個可能的條件，switch語句可能更合適。這樣，處理器可以評估語句，然後從一個答案列表中選擇下一步動作，而不用連續地評估一堆條件。列表6顯示的例子與列表5示例的類型相同。

列表6使用Switch語句

以上示例的寓意是，讓條件語句的選擇更開放，以選擇出最適合的語句。這種做法使程序結構更簡單，便於理解程序流程，縮短處理器的額外時鐘周期。

技巧4：避免使用彙編語言

微處理器的自然語言為彙編語言指令。為低級別機器語言編程可能會為處理器提供更高效的代碼。然而，人類並不是天生就會這種語言，並且經驗表明，編寫彙編語言會造成誤解。誤解會導致維護不當，更甚者，可能會使系統到處是bug.一般建議避免使用彙編語言。

實際上，現在大多數編譯器都能編譯出非常高效的代碼。采用C語言或C++語言等高級語言的開發，能獲得更有序的結構，便於理解和維護，使代碼的整體效果更好。列表7給出了一個示例，比較了使一個32位變量遞增所使用的彙編代碼和C語言代碼。

列表7用彙編和C語言完成一個變量的遞增

彙編

C代碼

當然，現在仍有一些場合適於使用彙編語言，但這種場合仍比較少。首個推薦的場合是開發引導裝載程序。這種情況下，可能需要優化對啟動過程中某個決策（啟動應用或引導加載器）的速度。此時，分支判定用彙編代碼就可能有意義了。

另一種場合是開發一種在DSP上運行有嚴格時序要求的控制循環。為了從設備中的得到每個時鐘周期，用彙編語言做控制循環的編碼是有意義的。如果目前任務適合用彙編，應確保將其妥善存檔便於有據可查，這樣，未來的開發者（或未來的版本）會明白該代碼的用途。

技巧5：充分利用模塊化

筆者最常見的經歷是著手由硬體工程師開啟的一個新項目往往是雜亂無章的代碼組織。通常我們會發現，代碼由一個單一的主模塊組成，其中有2.5萬多行代碼。在這些應用中，一切都是全局性的，函數寥寥無幾，goto語句貫穿整個代碼結構。15年前這算正常，但如今已不再適用了！

C語言編程使工程師能夠將代碼分成獨立的功能模塊，這簡化了代碼導航，同時還能夠使工程師使用封裝等面向對象技術。代碼可以被組織成邏輯模塊，這很有意義。雖然可能要先花點時間（幾分鐘），但從長遠來看，這將能省掉很多漫長之夜，和很多調試之苦！

技巧6：寫千層餅式代碼而非麵條式代碼

Beningo是一個義大利名字，和許多義大利人一樣，我對義大利麵食也是毫無保留地熱愛。當拿義大利麵食與軟體相比時，我就會想到兩種麵食，即義大利麵條和千層餅。義大利麵條比較混亂，麵條相互交織，縱橫交錯，結果完全沒有任何類型的結構。編寫非結構化代碼就非常像義大利麵條：咬一口，完全不知道吃的是哪部分。

另一種就是義大利千層餅！這種麵食是分層的，是有結構的。分層開發的代碼不僅更容易理解，還可以移走一層並添加一個新層，基本上能夠實現重複使用和維護的簡易性。圖1為用千層餅式代碼模型的一個簡單軟體模塊示例。

圖1千層餅軟件模型

　　驅動程序配置

　　應用程式配置

　　應用程式

　　驅動程序庫

　　硬體

技巧7：使用描述式變量名稱

編寫易於理解和維護的較大軟體有許多障礙，其中之一就是變量的命名習慣。為了盡力縮短變量名，開發者通常會自創一些較短的、令人費解的助記符，往往只有他們自己才能明白的符號。現代語言使一個變量名可以包含數百個字符。為了讓事情清晰明確，「直截了當」地方法要好於其它方式。因此，變量名一目了然不僅有利於開發人員，也有利於未來的維護團隊。列表8給出一個示例。

列表8變量的命名

技巧8：少用#pragma語句

C語言中有一種特殊的#pragma語句。這些語句通常處理非標準的句法和特性，應儘可能避免使用這種語句，因為它們是非標準的，不能從一個處理器移植到另一個處理器。有些編譯器可能要求用這類語句完成某項任務，例如定義一個中斷服務程序。

在這種情況下，可能除了使用#pragma語句以外別無它法。如果可能，將所有的#pragma語句放在一個模塊或幾個模塊里。這有助於確保在代碼移植時，只需要更新幾處代碼，而非整個代碼庫。此外，這也將有助於防止移植代碼的首次編譯所帶來的困擾。

技巧9：錯誤往往並不是看上去那樣簡單

在調試一個C程序時，有一個讓人當心的陷阱就是編譯器錯誤。由於編譯器的複雜性，當檢測到一個錯誤時，通常錯誤位於程序中的其它地方，而非編譯器所指示的位置。這主要與編譯器生成程序的步驟有關。錯誤類型通常是一致的，工程師可以發現的一些錯誤中，90%都是根源：

＊當心漏掉#include文件。這可能會使程序開發人員看到完美的代碼行，但由於未包含必要的頭文件，編譯器便會將其標誌為一個錯誤，表示有些東西未定義。

＊當心漏掉分號。編寫C代碼時最常見的錯誤是忘記在句末加分號。

＊當心漏掉括號。漏寫括號是代碼編寫過程中又一常犯的錯誤，或是粗心漏掉，或是由於鍵入錯誤而產生一個錯誤字符。

＊當心漏掉逗號。在複雜的定義中很容易忘記逗號！

一般情況下，當彈出一個奇怪的編譯錯誤對話框時，要查看該行前已被編譯的內容。很有可能就是錯誤所在！它可能是出現在一行上面，或中間部分，或在完全不同的文件里。

不要放棄！只要具備一定的經驗，解決這些疑難問題就會成為一種第二天性。

技巧10：優秀的程式設計師編寫的代碼行數不一定少

人們常有這種誤解，即認為較一般的程式設計師而言，一個優秀的程式設計師往往寫較少的代碼行就能解決問題。不要捲入這一錯誤的想法！一個優秀的程式設計師通常具備思維縝密、結構清晰的編碼基礎。變量命名和封裝都恰如其分，系統中幾乎不用全局變量。函數應保持簡短有效。如果代碼看起來很混亂，需要多寫幾行才能使其看上去更清晰，那就不妨多寫幾行！可以上網查看獲得C代碼編寫最混亂殊榮獎項的代碼用作前車之鑑。優秀程式設計師寫的代碼簡潔、易於理解和維護，代碼行數並非最少（圖2）！

圖2簡短程序