misra%202004規(guī)則doc

1、MISRA2004規(guī)則規(guī)則Jerry整理出處：汽車工業(yè)軟件可靠性聯(lián)會最后更新時間：2005720轉(zhuǎn)載請注明：來自Sawin系統(tǒng)分析之窗MISRA(TheMotIndustrySoftwareReliabilityAssociation汽車工業(yè)軟件可靠性聯(lián)會)是位于英國的一個跨國汽車工業(yè)協(xié)會，其成員包括了大部分歐美汽車生產(chǎn)商。其核心使命是為汽車工業(yè)提供服務和協(xié)助，幫助廠方開發(fā)安全的、高可靠性的嵌入式軟件。這個組織最出名的成果是所謂的MIS

2、RACCodingStard，這一標準中包括了127條C語言編碼標準，通常認為，如果能夠完全遵守這些標準，則你的C代碼是易讀、可靠、可移植和易于維護的。最近很多嵌入式開發(fā)者都以MISRAC來衡量自己的編碼風格，比如著名的uCOSII就得意地宣稱自己99％遵守MISRA標準。而《嵌入式開發(fā)雜志》也專門載文號召大家學習。編碼規(guī)范通常是一個公司自定的“土政策”，居然有人去做標準，而且還得到廣泛的認可，這不禁引起我強烈的興趣?？上н@份標準的文本

3、需要花錢去買，而且短短幾十頁，要價非常昂貴。MISRA在網(wǎng)上公布了一些文檔，其中有關于MISRACCodingStard的Clarification報告，從中間你可以大致猜到MISRA標準本身是什么。我仔細閱讀了這些文檔，并且通過閱讀其他一些介紹性文檔，大致了解了MISRA標準的主要內(nèi)容。這些條款確有過人之處，對于CC語言工程項目的代碼質(zhì)量管理能夠起到良好的指導性作用，對于大部分軟件開發(fā)企業(yè)來說，在MISRA的基礎上適當修改就可以形成自

4、己的規(guī)范。當然其中也有一些過于嚴苛的東西，這就需要各個開發(fā)部門靈活處理了。我個人的體會，編碼規(guī)范雖然很簡單，但是要完全執(zhí)行，不折不扣，需要開發(fā)部門有很高的組織性和紀律性，并且有很好的代碼評審機制。因此，如果能夠嚴格地遵守編碼規(guī)范，本身就是一個開發(fā)部門實力的證明。內(nèi)容內(nèi)容Rule1.1（強制）:所有的代碼應該遵守ISO9899:1990“ProgrammingLanguageC”Rule1.2（強制）:只有當具備統(tǒng)一接口的目標代碼的時候才

5、可以采用多種編譯器和語言Rule1.4（強制）檢查編譯器連接器以確保支持31一個有效字符，支持大小寫敏感Rule2.1(強制)：匯編語言應該封裝起來并且隔離：例如：#defineNOPasm(“NOP”)Rule2.2(強制):源代碼只能采用…風格的注釋Rule2.3(強制):字符序列不能在注釋中使用注:C語言不支持注釋的嵌套即使一些編譯器支持這個語言擴展Rule8.1(強制)：函數(shù)都應該有原型聲明，且相對函數(shù)定義和調(diào)用可見Rule8.

6、2(強制)：無論何時一個對象和函數(shù)聲明或者定義，它的類型應該明確聲明Rule8.5(強制):頭文件中不要定義對象或者函數(shù)Rule8.3(強制)：每個函數(shù)聲明中的參數(shù)的類型應該和定義中的類型一致Rule8.8(強制):外部變量或者函數(shù)只能聲明在一個文件中注：一般來講，聲明在頭文件中，然后包含在定義和使用的文件中Rule8.12(強制)：數(shù)組聲明為外部，應該明確聲明大小或者直接初始化確定例：externintarray2[]違反Rule8.

7、8Rule9.1(強制):所有變量在使用之前都應該賦值Rule10.1(強制):整型表達式不要隱式轉(zhuǎn)換為其他類型：a）轉(zhuǎn)換到更大的整型b）表達式太復雜c）表達式不是常數(shù)是一個函數(shù)d）表達式不是一個常數(shù)是一個返回表達式Rule10.2(強制)：浮點數(shù)表達式不要隱式轉(zhuǎn)換為其他類型：a）轉(zhuǎn)換到更大的浮點數(shù)b）表達式太復雜c）表達式是一個函數(shù)d）表達式是一個返回表達式Rule10.3(強制):整型表達式的值只能轉(zhuǎn)換到更窄小且是同樣符號類型的表達