來源：http://blog.csdn.net/lezhiyong
自用備忘與總結用，持續添加.....
一、代碼規範：
1、 用typedef定義統一的類型，只使用定義好的類型如：int8_x，uint8_x ，int16_x ，uint16_x，int32_x，uint32_x，float32_x，float64_x，int64_x，uint64_x類型可滿足項目的開發（x表示特定標識符）。詳細參見《 規範工程中c/c++變量類型的定義》：點擊打開鏈接
2、表達size的變量不要 size_t、int ，unsigned int 混用， 可統一使用size_t或 unsigned int（uint32_x）表述一方面可以防止類型轉換時候的數據改變，二可以根據代碼中的uint32和int32的定義清楚瞭解作者的意圖。
案例：編譯中出現:warning C4018: '>' : signed/unsigned mismatch
conversion from 'size_t' to 'int', possible loss of data
3、lib庫的包含：要麼在vs 的 工程屬性->linker->input和c++->genneral定義用相對路徑表述的庫和頭文件位置，要麼在接口頭文件中用 相對路徑include頭文件和lib庫。不要兩者混用，建議使用第一種方式，第二種方式對項目各工程文件的文件夾的層次結構有要求，否則包含時很容易出現 編譯link報錯：找不到某lib庫。
4、對外接口中的結構體、類名、函數名命名同樣命令風格.
案例：函數參數順序中是先輸入參數還是先輸出參數的問題，特別是接口頭文件中不要出現多種風格，造成調用者傳參失誤或閱讀困難。
5、windows函數使用UNICODE字符串函數，自win NT起，windows所有版本都是完全使用unicode來構建，如果傳入的是ANSI字符，windows系統也會轉換爲UNICODE,這些轉換會產生時間和內存開銷。
二、工程規範：
1、建立“通用底層庫”提供通用的操作函數，如安全字符串拷貝，文件路徑處理、時間處理、數字處理、字符串處理、通用宏SAFE_DELET SAFE_RELEASE等供整個項目使用，團隊成員都通過“通用庫”加入函數和使用函數，不要在各自工程內重複造輪子或私自造輪子。
2、分類各個頭文件及其內容的定義
有些頭文件是模塊提供的對外接口（需要與lib、dll配合使用），不同模塊的頭文件中放對應的內容，模塊間的接口頭文件內容不要交叉。
有些頭文件是一些模塊的宏定義和類型聲明（不帶cpp），聲明與定義數量多時候，儘量分類成幾個頭文件如：
typesDef.h 提供基本數據類型定義；macroDef.h 提供通用宏定義、inline函數；buildDef.h 提供編譯不同版本的宏定義；videoDef.h提供 視頻模塊的videoformat videosize 等結構體類型和宏定義;netDef.h定義網絡發送接收信令的ID與信令結構體
案例1：***ccom.h本來是用來定義com組件接口的頭文件，卻被某不熟悉規則的工程師在該頭文件中定義了很多RC資源ID，並在各ui模塊的resource.h中被包含，後來***ccom.h定義的一個組件接口需要增加一個函數，該函數使用了一個在 ***def.h定義的類型，於是在***ccom.hinclude了***Mediadef.h，這種做法本來沒什麼問題，但導致各ui模塊編譯時候出現找不到***Mediadef.h的錯誤。本來不耦合的com組件模塊和ui模塊因爲頭文件內容交叉被關聯到一起，並且***ccom.h頭文件的修改導致其他功能不相關的模塊也需要重編譯。
案例：開發文檔與代碼的文件夾管理問題：有的傾向代碼模塊內部創建一個文件夾存放該模塊相關的開發設計文檔，認爲文檔與代碼查閱方便，而且權限好設置，具備該模塊權限就能看到相應文檔。另外一種是與項目代碼文件夾並列建立一個文檔文件夾，完全與代碼分開，個人覺得完全分開好好點，1、方便代碼管理如持續集成下的更新檢測、代碼下載與打包，2、與代碼相比，文檔是更重要的核心資產，需要區分對待 ，2、分開放權限控制雖然複雜一些，但也可以一樣做好.
三、 項目規範
1、開發階段需求、編碼、用例與迭代的對接
2、版本驗證階段，開發與測試的對接
3、版本發佈階段，開發與測試的對接
數據流程：需求加入流程、問題單走單流程
內部管理：代碼版本管理（迭代開發與svn分支）、激勵制度
部門流程：測試與開發與系統
流程推動制度：問題單電子流、需求電子流、持續集成、責任人負責與推動