註釋嵌入式軟件的十大技巧

在軟件開發過程中沒有比獲得一個只有很少甚至沒有説明文檔的代碼庫而又要求進行維護更具挑戰性的事情了。這些文檔不只是告訴工程師某個特定函數或變量是做什麼的,而且能夠展示和傳達軟件為何以某個特定方式實現。在軟件實現過程中會作出成千上萬個決策,因此維護工程師甚至未來的你儘可能多地保留這些決策過程至關重要。

註釋嵌入式軟件的十大技巧

註釋代碼的問題部分原因來自出貨壓力、不正確的設計以及註釋代碼是如何工作的事情沒有開發來得有趣或興奮這個事實!許多工程師(包括我自己)憎恨必須註釋代碼,但這項工作在嵌入式工程師開發過程中是如此重要,以致於我們絕對不能省略或三意二意地去做。然而,可以在軟件開發過程中記住一些技巧,它們有助於確保未來開發人員維護好代碼開發中的任何細微變動。

  技巧1——隨時而不是過後進行註釋

交付產品的壓力經常導致天馬行空般的編碼風格,為了完成任務以便儘早推出產品,代碼是想到哪就編到哪。在瘋狂的代碼編寫過程中,很少想到記錄下代碼要完成的功能。等產品交貨後,設計人員才會回去瀏覽代碼並進行“註釋”。這樣做的問題是,這時已經距離寫完代碼幾周甚至幾個月的時間了!對一些工程師來説記起昨天早餐吃的是什麼都很難,更不用説兩週前寫的一段代碼了。最終結果是不準確的註釋説明,日後往往會引起誤解和缺陷。

這裏的技巧當然是在進行決策的同時隨時進行註釋。形式化的外部文檔註釋過程無疑會降低開發人員的進度,但向代碼庫中增加註釋真的不會佔用更多時間。開發人員能夠做的第一件事是先對代碼要做什麼事寫一些註釋行,然後再寫代碼。如果實現發生了變化,開發人員可以立即更新註釋。在任何情況下,在編寫代碼的同時寫下注釋只會節省時間和增加條理性,從而更少發生錯誤,產品也能更快的上市。

  技巧2——自動生成註釋文檔

儘管對代碼做了很詳細的註釋,但總是有生成外部文檔的要求,以便任何人不看代碼就能明白程序功能。這個要求經常導致雙倍的註釋工作量。幸運的是,市場上有現成的工具可以自動讀取代碼註釋、然後生成界面和代碼的其它文檔細節!幫助工程師避免必須做兩次相同的工作!一個具有這種功能的免費工具例子是Doxygen。當開發人員在編寫他們的代碼時,他們以指定方式格式化他們的註釋,並提供他們想要在外部文檔中展示的細節內容。然後他們就可以運行Doxygen生成真實反映軟件內註釋的html、rtf或pdf文檔。美妙的是如果你更新註釋,外部文檔也會自動更新!

  技巧3——不要寫顯式的註釋

雖然開發人員寫了代碼註釋,但如果註釋只是變量或函數名字的重複,會特別令人惱火。註釋應該是描述性的文字,需要提供顯式意思之外更多的細節!提供儘可能多的信息,而且不要忘了提及相關和關聯的變量或函數。開發人員應該能夠只通過閲讀註釋就瞭解軟件的行為。圖1給出了一個註釋簡單映射數組代碼的例子。

  技巧4——提供使用例子以便更清楚地瞭解用途

函數或變量註釋中包含如何使用它們的例子是很有用的。説應該如何使用是一回事,但展示如何使用會讓人更清楚其用途。除了能夠減少錯誤使用對象的機會外,還能給人一個更清晰的印象。圖2顯示了一個如何註釋函數的例子,它告訴開發人員應該如何使用這個函數,從而避免了容易出錯的猜測過程,使人能夠更清晰地瞭解其用途。

  技巧5——創建註釋標準

就像寫代碼一樣,為代碼開發註釋和文檔也應該有個標準。由於註釋標準中不可能有許多條款,因此特別推薦向編寫代碼標準靠攏。也就是説確保小組中的每個成員以相同的方式進行註釋和歸檔,從而確保開發的易用性。開發人員應該專注於解決手頭的設計問題,而不是費勁地去搞懂註釋。

  技巧6——使用文檔模板

確保註釋遵循標準的最容易的方法是為頭文件、源文件和支持文件創建模板。當創建一個新模塊時,可以從模板入手,然後增加相關的信息。這將有助於確保文件信息塊、代碼段、函數和變量都用相同的格式註釋。這種方法的最大優勢是能夠節省大量時間,並有助於減少將一個模塊拷貝到另一個偽模板時發生的`拷貝粘貼錯誤。為了讓生活更加輕鬆,我特意開發了可以用於定義頭文件和源文件的模板。

  技巧7——圖表的作用

在一個項目的軟件實現階段開始之前,應該有一個軟件設計階段。這個設計階段無疑會生成許多漂亮的圖(如流程圖和狀態機),並被用於實際實現。雖然這些文檔作為軟件的開發路線圖,但在開發和測試過程中總會出現偏差!遺憾的是,這些變化很少會返回到圖表中。結果是設計文檔和軟件的不匹配!在實現和測試階段將這些圖表放在手邊,以便發生上述偏差時這些圖表能及時得到更新。將這些圖表留到日後更新永遠不是正確的做法。雖然我們總是有返回去更新或修復的良好願望,但這永遠不是合適的時機。

  技巧8——保持註釋框使用的一致性

就像聽起來一樣奇怪,許多網絡爭論的內容是何時、哪裏使用何種類型的註釋框!不過嚴肅地講,不管你的信仰是什麼,歸根到底是一致性問題。如果一個團隊決定只使用/*…*/類型的註釋,那麼就只使用這種類型。如果決定使用//類型,那就只使用//類型。作者個人的觀點是傾向於使用/*…*/進行函數和模塊級説明,使用//進行函數代碼説明。不管選擇是什麼,確保每次都按同樣的方式去做,這樣有助於生活更加輕鬆。

  技巧9——使註釋更容易閲讀(即格式的美化)

為了確保避免誤解並由此產生代碼缺陷,使代碼保持結構化和容易閲讀很重要。註釋也一樣。偶爾結構化的註釋會使眼睛很難捕捉註釋,更難捕捉不在合適位置的內容。應該對註釋進行格式化處理,這樣如果代碼打印出來時(雖然現在不常打印,但我偶然仍會打印代碼)註釋就不會分到好幾頁上去。在大塊註釋(如文件頭或函數註釋)中,如果你使用塊指示器,千萬不要包含進任何拖尾字符(如#或*),要不只會使文檔更新變得更加困難。

  技巧10——嵌入圖像和圖表

藉助自動化工具的使用,在註釋文檔中包含編碼標準、縮寫詞、項目細節、要求和大量其它條款就成了可能。甚至能夠包含諸如流程圖等設計性圖表!使用這類功能允許代碼庫不僅包含執行代碼和邏輯,還包含你想要了解的項目所有內容,並且所有信息都放在同一個地方。