C 程式設計好習慣

2021-07-16 10:39:33 字數 2918 閱讀 8563

1.不要在建構函式中做初始化操作

要求類(尤其是對外介面類)提供init()函式,在該函式中進行相關初始化操作,初始化失敗能夠返回錯誤碼。

可以規避問題:

建構函式中難以返回錯誤碼,外部呼叫者無從判斷初始化結果。

當該類作為全域性變數使用時,構造函式呼叫發生在main()函式執行之前,出現問題難以追蹤。

2.所有函式返回值都要判斷

可以規避問題:

及時發現錯誤環節,終止處理流程,避免後續發生難以預料的錯誤。

3.關於函式返回值:

除了邏輯判斷函式外,函式返回值都為整型,且該返回值只能用來表示函式執**況(是否正確執行及錯誤碼)。禁止採用bool型別作為返回值來表示函式執**況。

避免void作為返回型別

返回值不能用來傳遞結果,結果資料可以採用引用型別的出參來實現。

返回值為整數時,其代表的含義統一規範為:小於0時表示執行錯誤;等於0時表示執行正確。

4.函式呼叫與錯誤日誌

任何函式呼叫失敗,必須記錄日誌。

避免無效的日誌:日誌中需要明確記錄錯誤碼(返回值)。除此之外,日誌中還需要記錄盡量多的上下文資訊,包括全部的入參資訊,具有相關性的成員變數資訊、全域性變數資訊等。

5.盡量不使用全域性變數。考慮採用成員變數或者main()中的區域性變數代替。

如果採用全域性變數,需要給出合適的解釋。

可以規避問題:

各種奇葩問題

6.全域性變數注意事項(如果一定要使用)

如果只在乙個cpp檔案中使用,那麼請使用靜態(static)全域性變數。例如static int a = 0;

如果需要跨cpp使用,那麼請使用較長且有區分度的名字來命名全域性變數。例如。int_g_model_section_object;(解決linux上全域性符號表識別錯誤問題)

確定該全域性變數類的建構函式中沒有進行複雜的初始化工作、是否依賴其他類。

清楚:c++標準沒有規定不同編譯單元(cpp檔案)中的全域性物件的構造順序,只規定了同一編譯單元中的全域性物件按照其定義的順序構造並倒序析構。

清楚:全域性變數初始化發生在main函式執行前,且沒有辦法捕獲到全域性物件初始化丟擲的異常。

7.使用陣列前要先判空。

未判空的情況下,使用下標0或者front()或者back()函式訪問陣列元素都是危險的。

8.函式入參檢查與出參復歸

防禦性程式設計:函式開始位置應對所有入參合法性、有效性進行檢測;

函式開始位置應該對所有出參進行清理和復歸工作;

9.字串拷貝函式

字串相關操作導致了太多問題。注意解決長度越界問題。

10.結構體與建構函式

結構體中如果使用了char陣列,必須在建構函式中給char陣列賦初值。

例如:

struct test

; char name[32];

};

慎用memset給結構體初始化,因為結構中可能有非連續變數型別,如string等。

錯誤示例:

struct test

;test test;

memset( &test, 0, sizeof( test ) );

11.函式入參

複雜物件(如vector)應採用引用方式作為入參,而不是值傳遞。

對於「引用入參」應該採用const修飾符。尤其注意字串入參應採用const char 型別,而不要採用char 。

12.」%s」與字串

注意printf等函式中」%s」與字串的對應關係,規避輸出崩潰問題。**review時,應著重檢查該類問題。

13.使用stdint.h定義的變數型別

建議採用stdint.h中定義的資料型別如int32_t、int64_t、uint32_t、uint64_t等,避免不同平台資料長度問題。

14.命名規則

原始碼檔名、動態庫名、執行程式名採用小寫字母+下劃線的組合方式。規避作業系統對大小寫字母敏感導致的各類問題。

15.減少重複**,優化結構設計

敗絮其中,難以金玉在外。要努力避免流水賬**、機械地拷貝、貼上、無設計的堆砌。相似**、相似功能盡量抽取出來,封裝為乙個內部公共函式。

16.動態庫中的結構體要定義在命名空間中

動態庫中所定義的結構體,要定義在專有的命名空間中。規避問題:避免動態庫與可執行程式之間結構體重名導致的各種問題。

17.switch-case語句中必須要有default語句,且default語句中應列印相關日誌資訊。

18.多執行緒

非執行緒安全的c函式。如struct tm *localtime(const time_t *timep);還有strtok、asctime、ctime、gmtime等等,使用時需要特別注意。

多執行緒共享的資源,使用前要先上線程鎖。stl模板庫是非執行緒安全的,例如多執行緒共享同乙個vector,那麼有關vector的任何操作前都需要使用鎖保護,即使呼叫的僅僅是size()函式。

關於執行緒的退出。不要試圖從外部強制殺掉某個執行緒,這樣做存在極大的記憶體洩漏風險。

19.配置檔案採用ini格式

除非ini格式不能滿足配置要求,否則應一律採用ini格式。

20.函式提前結束,做好資源釋放工作

若在某個程式分支中提前退出函式,請不要忘記釋放記憶體、資料庫控制代碼、檔案控制代碼等資源,否則會導致記憶體洩漏,資源耗盡。

舉例:

int test( int a )

...//其他操作

}

21.消缺與維護

克服僥倖心理,問題只要出現一次就肯定會出現第二次第三次….;

不要放過小問題,小問題可能遷出大問題;

不應通過「試」來解決問題,應尋找問題的根本原因;

修復bug需謹慎,全盤考慮,避免引入新bug。

程式設計好習慣

我們在編碼的時候總是希望能寫出風格良好,清晰 健壯的程式,把 當成一件藝術品來看待 來雕琢,讓 coding成為一種藝術。看了很多大牛關於程式設計風格與修養方面的文章,很受啟發,結合自己體會,簡錄幾條,提醒自己時刻注意。1.引數檢查 對於有引數的函式,首先要對引數的合法性進行檢查。可以利用asser...

程式設計好習慣

1.dry 不要重複你自己 don t repeat yourself dry是一條最容易理解但又是相對比較難以應用的原則。它是指當你在兩處或者更多的地方發現相似 時,我們應當把它們抽象成乙個新的函式,在之前重複的地方呼叫新的函式並帶上適當的引數。dry也許是最普遍的一條程式設計原則,我從未發現乙個...

C 編碼規範和程式設計好習慣

c 編碼規範和程式設計好習慣 撰文 dotnetspider.com 誰都會寫 幾個月的程式設計經驗可以讓你寫出 可執行應用程式 讓它可執行容易,但是以最有效率的方式編碼就需要下更多的功夫!要知道,大多數程式設計師在寫 可執行 而不是 高效 我們在這個指南課程前面提到,你想成為你們公司 最尊貴的專業...