規則一：為了防止標頭檔案被重複引用，應當用ifndef/define/endif結構產生預處理塊。
規則二：用 #include 格式來引用標準庫的標頭檔案（編譯器將從標準庫目錄開始搜尋）。
規則三：用 #include 「filename.h」 格式來引用非標準庫的標頭檔案（編譯器將從使用者的工作目錄開始搜尋）。
規則四：標頭檔案中只存放「宣告」而不存放「定義」.在c++語法中，類的成員函式可以在宣告的同時被定義，並且自動成為內聯函式。這雖然會帶來書寫上的方便，但卻造成了風格不一致，弊大於利。建議將成員函式的定義與宣告分開，不論該函式體有多麼小。
規則五：不提倡使用全域性變數，盡量不要在標頭檔案中出現象extern int value 這類宣告。
規則六：如果乙個軟體的標頭檔案數目比較多（如超過十個），通常應將標頭檔案和定義檔案分別儲存於不同的目錄，以便
於維護。
規則七：如果某些標頭檔案是私有的，它不會被使用者的程式直接引用，則沒有必要公開其「宣告」。為了加強資訊隱藏，
這些私有的標頭檔案可以和定義檔案存放於同乙個目錄。
規則八：在每個類宣告之後、每個函式定義結束之後都要加空行。
規則十一：if、for、while、do等語句自佔一行，執行語句不得緊跟其後。不論執行語句有多少都要加{}。這樣可以防止書寫失誤。
規則十二：盡可能在定義變數的同時初始化該變數（就近原則）如果變數的引用處和其定義處相隔比較遠，變數的初始化很容易被忘記。如果引用了未被初始化的變數，可能會導致程式錯誤。
規則十三：關鍵字之後要留空格。象const、virtual、inline、case等關鍵字之後至少要留乙個空格，否則無法辨析關鍵字。象if、for、while等關鍵字之後應留乙個空格再跟左括號『（』，以突出關鍵字。
規則十四：函式名之後不要留空格，緊跟左括號『（』，以與關鍵字區別。
規則十五：『（』向後緊跟，『）』、『，』、『;』向前緊跟，緊跟處不留空格。
規則十六：『，』之後要留空格，如function(x, y, z)。如果『;』不是一行的結束符號，其後要留空格，
如for
(initialization; condition; update)。
規則十七：賦值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符，如「=」、「+=」，「>=」、「<=」、「+」、「*」、「%」、「&&」、「||」、「<<」,「^」等二元操作符的前後應當加空格。
規則十九：象「［］」、「.」、「->」這類操作符前後不加空格。
規則二十：程式的分界符『』應獨佔一行並且位於同一列，同時與引用它們的語句左對齊。
規則二十一：}之內的**塊在『{』右邊數格處左對齊。
規則二十二：**行最大長度宜控制在70至80個字元以內。**行不要過長，否則眼睛看不過來，也不便於列印。
規則二十二：長表示式要在低優先順序操作符處拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要進行適當的縮排，使排版整齊，語句可讀。
規則二十三：應當將修飾符 * 和 ＆ 緊靠變數名。
規則二十四：注釋是對**的「提示」，而不是文件。程式中的注釋不可喧賓奪主，注釋太多了會讓人眼花繚亂。注釋的花樣要少。
規則二十五：如果**本來就是清楚的，則不必加注釋。否則多此一舉，令人厭煩。
規則二十六：邊寫**邊注釋，修改**同時修改相應的注釋，以保證注釋與**的一致性。不再有用的注釋要刪除。
規則二十七：注釋應當準確、易懂，防止注釋有二義性。錯誤的注釋不但無益反而有害。
規則二十八：盡量避免在注釋中使用縮寫，特別是不常用縮寫。
規則二十九：注釋的位置應與被描述的**相鄰，可以放在**的上方或右方，不可放在下方。
規則三十一：識別符號應當直觀且可以拼讀，可望文知意，不必進行「解碼」。識別符號最好採用英文單詞或其組合，便於記憶和閱讀。切忌使用漢語拼音來命名。程式中的英文單詞一般不會太複雜，用詞應當準確。例如不要currentvalue寫成nowvalue。
規則三十二：識別符號的長度應當符合「min-length && max-information」原則。
規則三十三：命名規則盡量與所採用的作業系統或開發工具的風格保持一致。例如windows應用程式的識別符號通常採用「大小寫」混排的方式，如addchild。而unix應用程式的識別符號通常採用「小寫加下劃線」的方式，如add_child。別把這兩類風格混在一起用。
規則三十四：程式中不要出現僅靠大小寫區分的相似的識別符號。
規則三十五：程式中不要出現識別符號完全相同的區域性變數和全域性變數，儘管兩者的作用域不同而不會發生語法錯誤，但會使人誤解。
規則三十六：變數的名字應當使用「名詞」或者「形容詞＋名詞」。
規則三十七：全域性函式的名字應當使用「動詞」或者「動詞＋名詞」（動賓片語）。類的成員函式應當只使用「動詞」，被省略掉的名詞就是物件本身。
規則三十八：用正確的反義詞組命名具有互斥意義的變數或相反動作的函式等。
規則三十九：盡量避免名字中出現數字編號，如value1,value2等，除非邏輯上的確需要編號。這是為了防止程式設計師偷懶，不肯為命名動腦筋而導致產生無意義的名字（因為用數字編號最省事）。
規則四十：類名和函式名用大寫字母開頭的單詞組合而成。
規則四十一：變數和引數用小寫字母開頭的單詞組合而成。
規則四十二：常量全用大寫的字母，用下劃線分割單詞。
規則四十三：靜態變數加字首s_（表示static）。
規則四十四：如果不得已需要全域性變數，則使全域性變數加字首g_（表示global）。
規則四十五：類的資料成員加字首m_（表示member），這樣可以避免資料成員與成員函式的引數同名。
規則四十六：為了防止某一軟體庫中的一些識別符號和其它軟體庫中的衝突，可以為各種識別符號加上能反映軟體性質的字首。例如三維圖形標準opengl的所有庫函式均以gl開頭，所有常量（或巨集定義）均以gl開頭。
規則四十七：如果**行中的運算子比較多，用括號確定表示式的操作順序，避免使用預設的優先順序。
規則四十八：不要編寫太複雜的復合表示式。不要有多用途的復合表示式。不要把程式中的復合表示式與「真正的數學表示式」混淆。
規則四十九：不可將布林變數直接與true、false或者1、0進行比較。應當將整型變數用「==」或「！=」直接與0比較。
規則五十：不可將浮點變數用「==」或「！=」與任何數字比較。千萬要留意，無論是float還是double型別的變數，都有精度限制。所以一定要避免將浮點變數用「==」或「！=」與數字比較，應該設法轉化成「>=」或「<=」形式。假設浮點變數的名字為x，應當將if (x == 0.0) // 隱含錯誤的比較轉化為if ((x>=-epsinon) && (x<=epsinon))其中epsinon是允許的誤差（即精度）。應當將指標變數用「==」或「！=」與null比較。
提高專案質量的一些方法
做了很多專案，每個專案都有不同的bug產生，如何減少bug產生的個數，如何避免重複的犯錯，最終的目的是去提高專案質量，就成為我們開發人員所需要關注的地方了。面對越來越多的變更需求，在敏捷開發中需要我們更多的提煉合適的方法去處理變化的需求。減少bug的產生，可以從幾個方面的維度去考慮 1.專案設計文件...
eslint 的一些規則
parenthese 圓括號 curly brace 花括號 comma 逗號 semicolon 分號 函式體中沒有花括號引數就不要有圓括號 物件中值必須要用單引號 定義但是沒有被使用，一般是可以被刪除的。有一種情況就是屬性驗證。proptypes沒有被使用，但是需要自己寫屬性驗證，所以就會被用上...
正則的一些規則
錨字元 邊界字元 行首匹配，和在裡的 不是乙個意思 行尾匹配 a 匹配字串開始，它和 的區別是,a只匹配整個字串的開頭，即使在re.m模式下也不會匹配它行的行首 z 匹配字串結束，它和 的區別是,z只匹配整個字串的結束，即使在re.m模式下也不會匹配它行的行尾 b 匹配乙個單詞的邊界，也就是值單詞和...