單片機匯編程序編碼規范

規則8

在多重循環中，應將最忙的循環放在最內層。

規則9

避免循環體內含判斷語句，將與循環變量無關的判斷語句移到循環體外。

目的是減少判斷次數。循環體中的判斷語句是否可以移到循環體外，要視程序的具體情況而言，一般情況，與循環變量無關的判斷語句可以移到循環體外，而有關的則不可以。

規則10

中斷和恢復

中斷程序應該盡量短，應該在中斷中進行標記，在主程序中處理。但實時性很高的程序段例外。

中斷時應該保存所有涉及到的通用變量和寄存器，如A, PSW, DPTR等。

規則11

堆棧設置

堆棧對于程序非常重要，對于堆棧的設置要合理。堆棧太小，在嵌套調用和很容易溢出，造成系統故障;堆棧太大，浪費RAM資源。

為了節約堆棧資源，中斷時要求不要保存太多資源，中斷嵌套和程序嵌套層數不要太多，盡量不要超過5層。這就要求合理的劃分功能模塊。

規則12

看門狗

看門狗電路用于在單片機死機時自動復位。單片機需要定時向看門狗發送脈沖，俗稱”喂狗”。喂狗不可太勤，這樣看門狗沒有起到作用;也不可太慢，這樣容易造成單片機復位。正確的喂狗應該在主循環中進行，最好是建立一個獨立的系統監控進程。不可以在定時中斷中喂狗，應為單片機有時可能會在主循環中死掉。

6.接口

規則1

去掉沒有必要的公共變量，編程時應盡量少用公共變量。

公共變量是增大模塊間耦合的原因之一，故應減少沒必要的公共變量以降低模塊間的耦合度。應該構造僅有一個模塊或函數可以修改、創建，而其余有關模塊或函數只訪問的公共變量，防止多個不同模塊或函數都可以修改、創建同一公共變量的現象。

規則2

當向公共變量傳遞數據時，要防止越界現象發生。

對公共變量賦值時，若有必要應進行合法性檢查，以提高代碼的可靠性、穩定性。

規則3

盡量不設計多參數函數，將不使用的參數從接口中去掉，降低接口復雜度，減少函數間接口的復雜度。

規則4

對所調用函數的返回碼要仔細、全面地處理。

防止把錯誤傳遞到后面的處理流程。如有意不檢查其返回碼，應明確指明。

規則5

檢查接口函數所有輸入參數的有效性。

規則6

檢查函數的所有非參數輸入，如外部數據、公共變量等。

7.代碼可測性

規則1

模塊編寫應該有完善的測試方面的考慮。

規則2

源代碼中應該設計了代碼測試的內容。

在編寫代碼之前，應預先設計好程序調試與測試的方法和手段，并設計好各種調測開關及相應測試代碼。

程序的調試與測試是軟件生存周期中很重要的一個階段，如何對軟件進行較全面、高率的測試并盡可能地找出軟件中的錯誤就成為很關鍵的問題。因此在編寫源代碼之前，除了要有一套比較完善的測試計劃外，還應設計出一系列代碼測試手段，為單元測試、集成測試及系統聯調提供方便。

規則3

在同一項目組或產品組內，要有一套統一的為集成測試與系統聯調準備的調測開關及相應函數，并且要有詳細的說明。本規則是針對項目組或產品組的。

規則4

在同一項目組或產品組內，調測打印出的信息串的格式要有統一的形式。信息串中至少要有所在模塊名(或源文件名)及行號。

統一的調測信息格式便于集成測試。

規則5

正式軟件產品中應把調測代碼去掉(即把有關的調測開關關掉)。

規則6

用調測開關來切換軟件的DEBUG版和正式版，而不要同時存在正式版本和DEBUG版本的不同源文件，以減少維護的難度。

規則7

在軟件系統中設置與取消有關測試手段，不能對軟件實現的功能等產生影響。

即有測試代碼的軟件和關掉測試代碼的軟件，在功能行為上應一致。

規則8

發現錯誤應該立即修改，并且若有必要記錄下來。

規則9

開發人員應堅持對代碼進行徹底的測試(單元測試)，而不依靠他人或測試組來發現問題。

規則10

清理、整理或優化后的代碼要經過審查及測試。

規則11

代碼版本升級要經過嚴格測試。

8.代碼編譯

規則1

打開編譯器的所有告警開關對程序進行編譯。

防止隱藏可能是錯誤的告警。

規則2

某些語句經編譯后產生告警，但如果你認為它是正確的，那么應通過某種手段去掉告警信息。

ps：從網上收集了一些相關內容，結合我自己的經驗，歡迎拍磚，謝絕辱罵;

ps2：有些可能不常用，因為大家寫不到那么長的代碼，就我自己寫的最長的匯編代碼也不超過10K行;