軟件設計更多地是一種工程，而不是一種個人藝術。如果不統(tǒng)一編程規(guī)范，最終寫出的程序，其可讀性將較差，這不僅給代碼的理解帶來障礙，增加維護階段的工作量，同時不規(guī)范的代碼隱含錯誤的可能性也比較大。

分析表明，編碼階段產生的錯誤當中，語法錯誤大概占20%左右，而由于未嚴格檢查軟件邏輯導致的錯誤、函數(shù)（模塊）之間接口錯誤及由于代碼可理解度低導致優(yōu)化維護階段對代碼的錯誤修改引起的錯誤則占了一半以上。

可見，提高軟件質量必須降低編碼階段的錯誤率。如何有效降低編碼階段的錯誤呢？這需要制定詳細的軟件編程規(guī)范，并培訓每一位程序員，最終的結果可以把編碼階段的錯誤降至10%左右，同時也降低了程序的測試費用，效果相當顯著。

本文從代碼的可維護性（可讀性、可理解性、可修改性）、代碼邏輯與效率、函數(shù)（模塊）接口、可測試性四個方面闡述了軟件編程規(guī)范，規(guī)范分成規(guī)則和建議兩種，其中規(guī)則部分為強制執(zhí)行項目，而建議部分則不作強制，可根據(jù)習慣取舍。

1．排版
規(guī)則1
程序塊使用縮進方式，函數(shù)和標號使用空格縮進，程序段混合使用TAB和空格縮進?？s進的目的是使程序結構清晰，便于閱讀和理解。
默認寬度應為8個空格，由于Word中為4個空格，為示范清晰，此處用2個代替(下同)。 

例如：
MOV R1, #00H
MOV R2, #00H
MOV PMR, #PMRNORMAL
MOV DPS, #FLAGDPTR
MOV DPTR, #ADDREEPROM
read1kloop:
read1kpage:
INC R1
MOVX A, @DPTR
MOV SBUF, A
JNB TI, $
CLR TI
INC DPTR
CJNE R1, #20H, read1kpage
INC R2
MOV R1, #00H
CPL WDI
CJNE R2, #20H, read1kloop ;END OF EEPROM

規(guī)則2 

在指令的操作數(shù)之間的，使用空格進行間隔，采用這種松散方式編寫代碼的目的是使代碼更加清晰。
例如：
CJNE R2, #20H, read1kloop ;END OF EEPROM

規(guī)則3
一行最多寫一條語句。

規(guī)則4
變量定義時，保持對齊。便于閱讀和檢查內存的使用情況。
例如：
RegLEDLOSS EQU 30H ; VARIABLE ; TESTLED==RegLEDLOSS.0
RegLEDRA EQU 31H ; VARIABLE
RUNLED_Flag EQU 32H ; VARIABLE ; 256ms改變一次RUNLED狀態(tài)
RUNLED_Def EQU 10H ; STATIC ; 16*32ms=500ms改變一次LED狀態(tài)


2．注釋
注釋的原則是有助于對程序的閱讀理解，注釋不宜太多也不能太少，太少不利于代碼理解，太多則會對閱讀產生干擾，因此只在必要的地方才加注釋，而且注釋要準確、易懂、盡可能簡潔。注釋量一般控制在30%到50%之間。

規(guī)則1
程序在必要的地方必須有注釋，注釋要準確、易懂、簡潔。
例如如下注釋意義不大：
MOV DXCE1COUNTER, #00H ; 將DXCE1COUNTER賦值為0
而如下的注釋則給出了額外有用的信息：
JNZ PcComm_Err ; 假如校驗出錯

規(guī)則2
注釋應與其描述的代碼相近，對代碼的注釋應放在其上方或右方（對單條語句的注釋）相鄰位置，不可放在下面，如放于上方則需與其上面的代碼用空行隔開。

規(guī)則3
頭文件、源文件的頭部，應進行注釋。注釋必須列出：文件名、作者、目的、功能、修改日志等。

規(guī)則4
函數(shù)頭部應進行注釋，列出：函數(shù)的目的、功能、輸入?yún)?shù)、輸出參數(shù)、涉及到的通用變量和寄存器、調用的其他函數(shù)和模塊、修改日志等。對一些復雜的函數(shù)，在注釋中最好提供典型用法。

規(guī)則5
對重要代碼段的功能、意圖進行注釋，提供有用的、額外的信息。并在該代碼段

的結束處加一行注釋表示該段代碼結束。

規(guī)則6
對于所有的常量，變量，數(shù)據(jù)結構聲明(包括數(shù)組、結構、類、枚舉等)，如果其命名不是充分自注釋的，在聲明時都必須加以注釋，說明其含義。

規(guī)則 7
維護代碼時，要更新相應的注釋，刪除不再有用的注釋。保持代碼、注釋的一致性，避免產生誤解。


3．命名
規(guī)則 1
標識符縮寫
形成縮寫的幾種技術：
1) 去掉所有的不在詞頭的元音字母。如screen寫成scrn, primtive寫成prmv。
2) 使用每個單詞的頭一個或幾個字母。如Channel Activation寫成ChanActiv，Release Indication寫成RelInd。
3) 使用變量名中每個有典型意義的單詞。如Count of Failure寫成FailCnt。
4) 去掉無用的單詞后綴 ing, ed等。如Paging Request寫成PagReq。
5) 使用標準的或慣用的縮寫形式（包括協(xié)議文件中出現(xiàn)的縮寫形式）。如BSIC(Base Station Identification Code)、MAP(Mobile Application Part)。
關于縮寫的準則：
1) 縮寫應該保持一致性。如Channel不要有時縮寫成Chan，有時縮寫成Ch。Length有時縮寫成Len，有時縮寫成len。
2) 在源代碼頭部加入注解來說明協(xié)議相關的、非通用縮寫。
3) 標識符的長度不超過12個字符。

規(guī)則2
變量命名約定：<前綴> + 主體 ; 注釋
變量命名要考慮簡單、直觀、不易混淆。
前綴是可選項，表示變量類型，由于匯編中變量多是單字節(jié)變量，所以單字節(jié)變量可以不加前綴，對于bit和雙字節(jié)型變量，使用小寫的b和d作為前綴表示。
主體是必選項，可多個單詞(或縮寫)合在一起，每個單詞首字母大寫，其余部分小寫。

規(guī)則3
常量的命名
常量的命名規(guī)則：單詞的字母全部大寫，各單詞之間用下劃線隔開。

規(guī)則4
函數(shù)的命名
單詞首字母為大寫，其余均為小寫。函數(shù)名應以一個動詞開頭，即函數(shù)名應類似一個動詞斷語或祈使句。

例如：Test_Protect， Check_EEPROM， Init_Para


4．可維護性
規(guī)則1
函數(shù)和過程中關系較為緊密的代碼盡可能相鄰。

規(guī)則2
每個函數(shù)的源程序行數(shù)原則上應該少于200行。
對于消息分流處理函數(shù)，完成的功能統(tǒng)一，但由于消息的種類多，可能超過200行的限制，不屬于違反規(guī)定。

規(guī)則3
語句嵌套層次不得超過5層。
嵌套層次太多，增加了代碼的復雜度及測試的難度，容易出錯，增加代碼維護的難度。

規(guī)則4
避免相同的代碼段在多個地方出現(xiàn)。
當某段代碼需在不同的地方重復使用時，應根據(jù)代碼段的規(guī)模大小使用函數(shù)調用或宏調用的方式代替。這樣，對該代碼段的修改就可在一處完成，增強代碼的可維護性。

規(guī)則5
每個函數(shù)完成單一的功能，不設計多用途面面俱到的函數(shù)。
多功能集于一身的函數(shù)，很可能使函數(shù)的理解、測試、維護等變得困難。使函數(shù)功能明確化，增加程序可讀性，亦可方便維護、測試。

規(guī)則6
在函數(shù)的項目維護文檔中，應該指出軟件適用的硬件平臺及版本。


建議1
使用專門的初始化函數(shù)對所有的公共變量進行初始化。


5．程序正確性、效率
規(guī)則1
嚴禁使用未經初始化的變量。
引用未經初始化的變量可能會產生不可預知的后果，特別是引用未經初始化的指針經常會導致系統(tǒng)崩潰，需特別注意。

規(guī)則2
防止內存操作越界。 

說明：內存操作越界是軟件系統(tǒng)主要錯誤之一，后果往往非常嚴重。

規(guī)則3
注意變量的有效取值范圍，防止表達式出現(xiàn)上溢或下溢。

規(guī)則4
防止易混淆的指令和操作數(shù)拼寫錯誤。

規(guī)則5
避免函數(shù)中不必要語句，防止程序中的垃圾代碼，預留代碼應以注釋的方式出現(xiàn)。
程序中的垃圾代碼不僅占用額外的空間，而且還常常影響程序的功能與性能，很可能給程序的測試、維護等造成不必要的麻煩。

規(guī)則6
通過對系統(tǒng)數(shù)據(jù)結構的劃分與組織的改進，以及對程序算法的優(yōu)化來提高空間效率。
這種方式是解決軟件空間效率的根本辦法。

規(guī)則7
循環(huán)體內工作量最小化。
應仔細考慮循環(huán)體內的語句是否可以放在循環(huán)體之外，使循環(huán)體內工作量最小，從而提高程序的時間效率。

規(guī)則8
在多重循環(huán)中，應將最忙的循環(huán)放在最內層。

規(guī)則9
避免循環(huán)體內含判斷語句，將與循環(huán)變量無關的判斷語句移到循環(huán)體外。
目的是減少判斷次數(shù)。循環(huán)體中的判斷語句是否可以移到循環(huán)體外，要視程序的具體情況而言，一般情況，與循環(huán)變量無關的判斷語句可以移到循環(huán)體外，而有關的則不可以。

規(guī)則10
中斷和恢復
中斷程序應該盡量短，應該在中斷中進行標記，在主程序中處理。但實時性很高的程序段例外。
中斷時應該保存所有涉及到的通用變量和寄存器，如A, PSW, DPTR等。

規(guī)則11
堆棧設置
堆棧對于程序非常重要，對于堆棧的設置要合理。堆棧太小，在嵌套調用和很容易溢出，造成系統(tǒng)故障；堆棧太大，浪費RAM資源。
為了節(jié)約堆棧資源，中斷時要求不要保存太多資源，中斷嵌套和程序嵌套層數(shù)不要太多，盡量不要超過5層。這就要求合理的劃分功能模塊。 

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


6．接口
規(guī)則1
去掉沒有必要的公共變量，編程時應盡量少用公共變量。
公共變量是增大模塊間耦合的原因之一，故應減少沒必要的公共變量以降低模塊間的耦合度。應該構造僅有一個模塊或函數(shù)可以修改、創(chuàng)建，而其余有關模塊或函數(shù)只訪問的公共變量，防止多個不同模塊或函數(shù)都可以修改、創(chuàng)建同一公共變量的現(xiàn)象。

規(guī)則2
當向公共變量傳遞數(shù)據(jù)時，要防止越界現(xiàn)象發(fā)生。
對公共變量賦值時，若有必要應進行合法性檢查，以提高代碼的可靠性、穩(wěn)定性。

規(guī)則3
盡量不設計多參數(shù)函數(shù)，將不使用的參數(shù)從接口中去掉，降低接口復雜度，減少函數(shù)間接口的復雜度。

規(guī)則4
對所調用函數(shù)的返回碼要仔細、全面地處理。
防止把錯誤傳遞到后面的處理流程。如有意不檢查其返回碼，應明確指明。

規(guī)則5
檢查接口函數(shù)所有輸入?yún)?shù)的有效性。

規(guī)則6
檢查函數(shù)的所有非參數(shù)輸入，如外部數(shù)據(jù)、公共變量等。


7．代碼可測性
規(guī)則1
模塊編寫應該有完善的測試方面的考慮。

規(guī)則2
源代碼中應該設計了代碼測試的內容。
在編寫代碼之前，應預先設計好程序調試與測試的方法和手段，并設計好各種調測開關及相應測試代碼。 

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

規(guī)則3
在同一項目組或產品組內，要有一套統(tǒng)一的為集成測試與系統(tǒng)聯(lián)調準備的調測開關及相應函數(shù)，并且要有詳細的說明。本規(guī)則是針對項目組或產品組的。

規(guī)則4
在同一項目組或產品組內，調測打印出的信息串的格式要有統(tǒng)一的形式。信息串中至少要有所在模塊名（或源文件名）及行號。
統(tǒng)一的調測信息格式便于集成測試。

規(guī)則5
正式軟件產品中應把調測代碼去掉（即把有關的調測開關關掉）。

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

規(guī)則7
在軟件系統(tǒng)中設置與取消有關測試手段，不能對軟件實現(xiàn)的功能等產生影響。
即有測試代碼的軟件和關掉測試代碼的軟件，在功能行為上應一致。

規(guī)則8
發(fā)現(xiàn)錯誤應該立即修改，并且若有必要記錄下來。

規(guī)則9
開發(fā)人員應堅持對代碼進行徹底的測試（單元測試），而不依靠他人或測試組來發(fā)現(xiàn)問題。

規(guī)則10
清理、整理或優(yōu)化后的代碼要經過審查及測試。

規(guī)則11
代碼版本升級要經過嚴格測試。


8．代碼編譯
規(guī)則1
打開編譯器的所有告警開關對程序進行編譯。
防止隱藏可能是錯誤的告警。 

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