寫在前面 Ⅰ
不知道大家有沒有這樣的感受:看到不規(guī)范(雜亂差)的代碼,瞬間就沒有看下去的欲望了。
相信大家看到標題都應該能明白編程的規(guī)范及原則對于每一個軟件開發(fā)的工程師來說是多么重要。
初學者編寫測試程序、小的模塊程序也許不能感受它的重要性;但有經驗及大型項目開發(fā)的人就知道程序的規(guī)范性對他們來說是有多么的重要。
關于編程規(guī)范及原則 Ⅱ
編程規(guī)范也就是編寫出簡潔、可維護、可靠、可測試、高效、可移植的代碼,提高產品代碼的質量。
本文針對嵌入式,主要結合C語言編程的規(guī)范給大家講述。
1.頭文件
對于C語言來說,頭文件的設計體現(xiàn)了大部分的系統(tǒng)設計,不合理的頭文件布局是編譯時間過長的原因。
有很多人將工程中所有的頭文件包含在一個include.h文件中,然后在每一個.c源代碼文件中包含include.h頭文件,這樣做可以讓代碼看上去簡潔,但實際忽視了編譯效率問題,而且代碼的可移植性也不好。
原則:
A.頭文件中適合放置接口的聲明,不適合放置實現(xiàn);
B.頭文件應當職責單一;
C.頭文件應向穩(wěn)定的方向包含。
規(guī)則:
A.每一個.c文件應有一個同名.h文件,用于聲明需要對外公開的接口;
B.禁止頭文件循環(huán)依賴;
C..c/.h文件禁止包含用不到的頭文件;
D.頭文件應當自包含;
E.總是編寫內部#include保護符( #define 保護);
F.禁止在頭文件中定義變量;
G.只能通過包含頭文件的方式使用其他.c提供的接口,禁止在.c中通過extern的方式使用外部函數接口、變量;
H.禁止在extern "C"中包含頭文件。
建議:
A.一個模塊通常包含多個.c文件,建議放在同一個目錄下,目錄名即為模塊名。為方便外部使用者,建議每一個模塊提供一個.h,文件名為目錄名;
B.如果一個模塊包含多個子模塊,則建議每一個子模塊提供一個對外的.h,文件名為子模塊名(降低接口使用者的編寫難度);
C.頭文件不要使用非習慣用法的擴展名,如.inc;
D.同一產品統(tǒng)一包含頭文件排列方式。
2.函數
函數設計的要點:編寫整潔的函數,同時把代碼有效組織起來。
函數整潔的要求:代碼簡單直接、不隱藏設計者的意圖、用干凈利落的抽象和直截了當的控制語句將函數有機組織起來。
原則:
A.一個函數僅完成一件功能;
B.重復代碼應該盡可能提煉成函數.
規(guī)則:
A.避免函數過長,新增函數不超過100行(非空非注釋行);
B.避免函數的代碼塊嵌套過深,新增函數的代碼塊嵌套不超過4層;
C.可重入函數應避免使用共享變量;若需要使用,則應通過互斥手段(關中斷、信號量)對其加以保護;
D.對參數的合法性檢查,由調用者負責還是由接口函數負責,應在項目組/模塊內應統(tǒng)一規(guī)定;
E.對函數的錯誤返回碼要全面處理;
F.設計高扇入,合理扇出(小于7)的函數;
G.廢棄代碼(沒有被調用的函數和變量)要及時清除。
建議:
A.函數不變參數使用const;
B.函數應避免使用全局變量、靜態(tài)局部變量和I/O操作,不可避免的地方應集中使用;
C.檢查函數所有非參數輸入的有效性,如數據文件、公共變量等;
D.函數的參數個數不超過5個;
E.除打印類函數外,不要使用可變長參函數;
F.在源文件范圍內聲明和定義的所有函數,除非外部可見,否則應該增加static關鍵字。
3.標識符命名與定義
程序命名是一個關鍵,如果命名不規(guī)范,自己寫的代碼,時間長了恐怕連自己都不知道是什么意思了。
3.1通用命名規(guī)則
常見命名風格:
A.用下劃線?_?分割,如text_mutex;
規(guī)則:
A.標識符的命名要清晰、明了,有明確含義,同時使用完整的單詞或大家基本可以理解的縮寫,避免使人產生誤解;
B.除了常見的通用縮寫以外,不使用單詞縮寫,不得使用漢語拼音;
C.產品/項目組內部應保持統(tǒng)一的命名風格.
建議:
A.用正確的反義詞組命名具有互斥意義的變量或相反動作的函數等;
B.盡量避免名字中出現(xiàn)數字編號,除非邏輯上的確需要編號;
C.標識符前不應添加模塊、項目、產品、部門的名稱作為前綴;
D.平臺/驅動等適配代碼的標識符命名風格保持和平臺/驅動一致;
E.重構/修改部分代碼時,應保持和原有代碼的命名風格一致。
3.2 文件命名規(guī)則
因為不同系統(tǒng)對文件名大小寫處理會不同,建議文件命名統(tǒng)一采用小寫字符。
3.3 變量命名規(guī)則
首先,全局變量十分危險,通過前綴使得全局變量更加醒目, 促使開發(fā)人員對這些變量的使用更加小心。
其次,從根本上說,應當盡量不使用全局變量,增加g_和s_前綴,會使得全局變量的名字顯得很丑陋,從而促使開發(fā)人員盡量少使用全局變量。
規(guī)則:
A.全局變量增加“g_”前綴,靜態(tài)變量增加“s_”前綴;
B.禁止使用單字節(jié)命名變量,但允許定義i、 j、 k作為局部循環(huán)變量;
C.使用名詞或者形容詞+名詞方式命名變量。
3.4 函數命名規(guī)則
A.函數命名應以函數要執(zhí)行的動作命名,一般采用動詞或者動詞+名詞的結構;
B.函數指針除了前綴,其他按照函數的命名規(guī)則命名。
3.5 宏的命名規(guī)則
A.對于數值或者字符串等等常量的定義,建議采用全大寫字母,單詞之間加下劃線?_?的方式命名(枚舉同樣建議使用此方式定義);
B.除了頭文件或編譯開關等特殊標識定義,宏定義不能使用下劃線?_?開頭和結尾。
4.變量
原則:
A.一個變量只有一個功能,不能把一個變量用作多種用途;
B.結構功能單一;不要設計面面俱到的數據結構;
C.不用或者少用全局變量。
規(guī)則:
A.防止局部變量與全局變量同名;
B.通訊過程中使用的結構,必須注意字節(jié)序;
C.嚴禁使用未經初始化的變量作為右值;
建議:
A.構造僅有一個模塊或函數可以修改、創(chuàng)建,而其余有關模塊或函數只訪問的全局變量,防止多個不同模塊或函數都可以修改、創(chuàng)建同一全局變量的現(xiàn)象;
B.使用面向接口編程思想,通過API訪問數據:如果本模塊的數據需要對外部模塊開放,應提供接口函數來設置、獲取,同時注意全局數據的訪問互斥;
C.在首次使用前初始化變量,初始化的地方離使用的地方越近越好;
D.明確全局變量的初始化順序,避免跨模塊的初始化依賴;
E.盡量減少沒有必要的數據類型默認轉換與強制轉換。
5.宏、常量
因為宏只是簡單的代碼替換,不會像函數一樣先將參數計算后,再傳遞。
規(guī)則:
A.用宏定義表達式時,要使用完備的括號;
不規(guī)范:#defineRECTANGLE_AREA(a, b) a * b
規(guī)范:#defineRECTANGLE_AREA(a, b) ((a) * (b))
B.將宏所定義的多條表達式放在大括號中;
C.使用宏時,不允許參數發(fā)生變化;
#define SQUARE(a) ((a) * (a))
int a = 5;
int b;
不規(guī)范:
b = SQUARE(a++);
規(guī)范:
b = SQUARE(a);
a++;
建議:
A.除非必要,應盡可能使用函數代替宏;
B.常量建議使用const定義代替宏;
C.宏定義中盡量不使用return、 goto、 continue、 break等改變程序流程的語句。
6.注釋
原則:
A.優(yōu)秀的代碼可以自我解釋,不通過注釋即可輕易讀懂;
B.注釋的內容要清楚、明了,含義準確,防止注釋二義性;
C.在代碼的功能、意圖層次上進行注釋,即注釋解釋代碼難以直接表達的意圖,而不是重復描述代碼。
規(guī)則:
A.修改代碼時,維護代碼周邊的所有注釋,以保證注釋與代碼的一致性。不再有用的注釋要刪;
B.文件頭部應進行注釋,注釋必須列出:版權說明、版本號、生成日期、作者姓名、工號、內容、功能說明、與其它文件的關系、修改日志等,頭文件的注釋中還應有函數功能簡要說明;
C.函數聲明處注釋描述函數功能、性能及用法,包括輸入和輸出參數、函數返回值、可重入的要求等;定義處詳細描述函數功能和實現(xiàn)要點,如實現(xiàn)的簡要步驟、實現(xiàn)的理由、 設計約束等;
D.全局變量要有較詳細的注釋,包括對其功能、取值范圍以及存取時注意事項等的說明;
E.注釋應放在其代碼上方相鄰位置或右方,不可放在下面。 如放于上方則需與其上面的代碼用空行隔開,且與下方代碼縮進相同;
F.避免在注釋中使用縮寫,除非是業(yè)界通用或子系統(tǒng)內標準化的縮寫;
G.同一產品或項目組統(tǒng)一注釋風格。
建議:
A.避免在一行代碼或表達式的中間插入注釋;
B.文件頭、函數頭、全局常量變量、類型定義的注釋格式采用工具可識別的格式。
7.排版與格式
規(guī)則:
A.程序塊采用縮進風格編寫, 每級縮進為4個空格;
B.相對獨立的程序塊之間、變量說明之后必須加空行;
C.一條語句不能過長,如不能拆分需要分行寫。一行到底多少字符換行比較合適,產品可以自行確定;
D.多個短語句(包括賦值語句)不允許寫在同一行內,即一行只寫一條語句;
E.if、 for、 do、 while、 case、 switch、 default等語句獨占一行;
F.在兩個以上的關鍵字、變量、常量進行對等操作時,它們之間的操作符之前、之后或者前后要加空格; 進行非對等操作時,如果是關系密切的立即操作符(如->),后不應加空格;
G.注釋符(包括?/*??//??*/?)與注釋內容之間要用一個空格進行分隔。
說明 Ⅲ
關于編程規(guī)范、原則等相關的文章在國外很多優(yōu)秀的工程師都總結的有:
http://www.artima.com/weblogs/viewpost.jsp?thread=331531
良好的編程習慣是需要日積月累的,如果你處于學習階段,請你時刻要注意這些細節(jié)問題。
-
C語言
+關注
關注
180文章
7594瀏覽量
135857 -
編程
+關注
關注
88文章
3565瀏覽量
93536 -
開發(fā)編程
+關注
關注
0文章
4瀏覽量
5746
發(fā)布評論請先 登錄
相關推薦
評論