一、說在前面：
建議參考：https://blog.csdn.net/weixin_30550271/article/details/99085561
二、前言
1、“代碼規范”可以分成兩個部分。
（1）代碼風格規范。主要是文字上的規定，看似表面文章，實際上非常重要。
（2）代碼設計規范。牽涉到程序設計、模塊之間的關系、設計模式等方方面面，這里有不少與具體程序設計語言息息相關的內容（如C/C++/Java/C#），但是也有通用的原則。
這里主要討論通用的原則。
2、代碼風格的原則是：簡明，易讀，無二義性。
三、幾個建議
1、代碼規范-縮進：用好TAB鍵，在VS2005和其他的一些編輯工具中都可以定義Tab鍵擴展成為幾個空格鍵。用 Tab鍵的理由是Tab鍵在不同的情況下會顯示不同的長度。4個空格的距離從可讀性來說正好。
2、代碼規范-行寬：建議每行不超過100個字符
3、代碼規范-括號：在復雜的條件表達式中，用括號清楚地表示邏輯優先級。
4、代碼規范-斷行與空白的{ }行：每個“{”和“}”都獨占一行。可以清楚的知道括號的匹配關系：
if ( condition) { DoSomething(); } else { DoSomethingElse(); }
5、代碼規范-分行：不要把多行語句放在一行上。
6、代碼規范-命名：大家都知道用單個字母給有復雜語義的實體命名是不好的，目前最通用的，也是經過了實踐檢驗的方法叫“匈牙利命名法”
例如：
fFileExist，表明是一個bool值，表示文件是否存在；
szPath，表明是一個以0結束的字符串，表示一個路徑。
總結:以兩條規則為基礎：
（1）標識符的名字以一個或者多個小寫字母開頭，用這些字母來指定數據類型。
（2）在標識符內，前綴以后就是一個或者多個第一個字母大寫的單詞，這些單詞清楚地指出了源代碼內那個對象的用途。比如，m_szStudentName表示一個學生名字的類成員變量，數據類型是字符串型。
7、代碼規范-下划線問題：下划線用來分隔變量名字中的作用域標注和變量的語義，如：一個類型的成員變量通常用m_來表示。
8、 代碼規范-大小寫問題：
（1）由多個單詞組成的變量名，如果全部都是小寫，很不易讀，一個簡單的解決方案就是用大小寫區分它們。
（2）Pascal——所有單詞的第一個字母都大寫；
（3）Camel——第一個單詞全部小寫，隨后單詞隨Pascal格式，這種方式也叫lowerCamel。
（4）一個通用的做法是：所有的類型/類/函數名都用Pascal形式，所有的變量都用Camel形式。
（5）類/類型/變量：名詞或組合名詞，如Member、ProductInfo等。
（6）函數則用動詞或動賓組合詞來表示，如get/set; RenderPage()。
9、代碼規范-注釋：
（1）注釋也要隨着程序的修改而不斷更新，一個誤導的（Misleading）注釋往往比沒有注釋更糟糕。
（2）另外，注釋（包括所有源代碼）應只用ASCII字符，不要用中文或其他特殊字符，它們會極大地影響程序的可移植性。
（3）在現代編程環境中，程序編輯器可以設置各種好看的字體，可以使用不同的顯示風格來表示程序的不同部分。
（4）注意: 有些程序設計語言的教科書對於基本的語法有詳細的注釋, 那是為了教學的目的, 不宜在正式項目中也這么做。
（5）復雜的注釋應該放在函數頭，很多函數頭的注釋都是解釋參數的類型等的，如果程序正文已經能夠說明參數的類型in/out等，就不要重復！
（6）不要注釋程序是怎么工作的（How），你的程序本身就應該能說明這一問題。