赫墨拉遊戲-服務端-編程規範

爲了方便你們交流和代碼共享，如今此作出一個共同的代碼風格約定。本規範適用於項目C++語言以及其餘語言與C++的交集部分。

PS：本規範只對預計可能致使代碼風格有較大不一樣的部分做出約定。

1、命名規範

對於全部類型的命名都有效的規範：

命名是很是重要的，

l  名稱表述清楚，使用統一的英文詞彙。

l  不使用英文簡寫，除非是一些固有的縮略語。

l  單詞命名優先表達清楚意思，其次才考慮縮短長度，不過也不要太長。

l  對於沒法用英文表述的命名，使用拼音。每一個詞看作一個單詞，中間不用大寫，

例如：

修仙副本 xiuxianCopy

炫陽套裝 xuanyangSuit

由於漢字太多的話，大寫太多會很亂。

l  使用駝峯命名法，嚴禁全字母大寫而且沒有」_」的命名。

l  全部函數、變量、類等，都必需要加註釋，即便一看就懂的也翻譯一下中文。

l  命名要一致，不一樣的功能，對於相同的概念，要用相同的名稱。

 

1．           變量命名規範

l  變量名前不使用任何表示類型的前綴。

l  類內部數據成員，之前綴「_」開頭；對於公開的數據成員，能夠不使用前綴。

l  變量首字母使用小寫。

2．           函數命名規範

l  函數名必須直觀，而且能正確表達其內在功能。

l  對於函數參數中的引用和指針類型視狀況以const修飾。

l  對於不修改數據成員的類成員函數，以const修飾。

l  函數名以小寫開頭。

3．           類和結構名命名規範

l  類名以C開頭，結構以S開頭，都以大寫開頭。

l  接口類的命名沿用上面規則，並之前綴「I」開頭，例如：IInterfaceMgr，IModule。

4．           常量與宏命名規範

l  儘可能不使用宏定義；

l  對於常數定義，儘可能採用const修飾或enum定義；

l  對於簡單的操做，採用inline函數方式定義；

l  常量名第一個字母大寫。

5．           文件命名規範

l  目錄名每一個單詞首字母大寫，不使用任何分隔符；

6．           typedef類型命名規範

l  typedef std::vector<int> SeqInt; //vector的所有都在前面加Seq。

l  typedef ::std::map<int, int> DictIntInt;//map在cdl中加前綴Dict，在代碼中用Map。

l  必須以大寫開頭。

2、佈局規範

應當以IDE的原來的風格爲優先。

l  程序體建議以TAB縮進，少使用空格縮進。

l  每個函數（或類方法）之間至少保留一個空行。

l  在程序體內，具備語義轉換時，必須保留一個空行。

l  不編寫過長的函數代碼，若是函數過長應該考慮分拆爲多個函數。

l  屢次使用的代碼，儘可能抽出來做爲一個函數。

l  除「.」、「→」、「::」外，雙目操做符（如：「+」、「*=」等），兩側各留一個空格。

l  單目操做符（如：「++」、「!」）與操做數之間不留空格。

l  逗號分隔符的左側不留空格，右側留一個空格。

l  當判斷一個指針是否爲空時，使用「!ptr」的形式判斷。

l  不要在同一行了聲明多個變量。

l  當一個函數的返回值是指針變量或引用變量時，類型與操做符（「*」或「&」）之間不留空格，操做符以後留一個空格；

l  對於複合語句，如：while, for, if等，不管複合語句中包含多少個語句，一概另起一行，並使用{}括起來；

l  儘可能保持頭文件中不包含頭文件；

l  對於數據成員都公開的類，使用struct關鍵字來定義，不然使用class關鍵字。

l  對於計數器或迭代器，可以使用前++(--)或後++ (--)時，一概使用前++(--)。

 

一些很是細的規則能夠看這裏：

http://blog.csdn.net/u012175089/article/details/51078360

 

3、編碼的建議

這裏只是一些建議和可能遇到的問題。

 

1.儘可能把運算提早，可以在啓動程序時進行的運算，就不要等到使用的時候才進行。

例如對於某些用[xxx,yyy]這樣包着的字符串，應該在初始化的時候就進行分解，用DictIntInt來保存。而不是每次用到的時候拆一下。

又如每一級的屬性，在升級以後，一個個再加起來。這是設計上的錯誤，在設計配置文件的時候，要充分考慮計算量。同時也要考慮策劃的配置量，一般只要配一次，之後改動很小的數據就不須要考慮策劃的工做量了。

2.內存中的配置文件，儘可能使用map來代替vector。

3.代碼裏面的code不少，物品、技能、buff、updateCode等等，幾乎每一個配置都有一個，最好在使用的時候加上各自的單詞，例如：itemCode，skillCode，buffCode等等，不能只寫code，難以閱讀，並且代碼增多以後很容易形成混亂。

4.儘可能使用公共的工具類函數，通常都放在Common/Public目錄下，Util類是最經常使用的。

5.字符串拼接，通常使用「,」，若是要加多一層，建議使用「;」。使用公用的函數來構建和分解字符串。

6.DataTime轉成int，能夠去到2030年之後都不會出錯，使用json保存的時候，能夠放心使用int，方便比較，減小轉換，並且減小json的長度。

7.智能指針不要互相指引，不然沒法自動析構。

8.json原則上是用來保存一些比較散亂的字段，若是是有多個字段的結構的數組，能夠考慮構建一個新的表。Json字段一般很大，若是是數組，很容易會超過最大長度。並且，很難調試和查看內存。Json最大的用途是用來存儲和傳輸，不要過度依賴。沒法調試的。

9.保存到數據庫的數據，儘可能使用延時保存。

10.不要寫依賴於順序而毫無邏輯的代碼。

sCodeAttribute.attribute.push_back(attr.attack);  
sCodeAttribute.attribute.push_back(attr.life);  
sCodeAttribute.attribute.push_back(attr.physicalDefense);  
sCodeAttribute.attribute.push_back(attr.magicalDefense);  
sCodeAttribute.attribute.push_back(attr.wreck);  
sCodeAttribute.attribute.push_back(attr.block);  
sCodeAttribute.attribute.push_back(attr.miss);  
sCodeAttribute.attribute.push_back(attr.demiss);  
sCodeAttribute.attribute.push_back(attr.crit);  
sCodeAttribute.attribute.push_back(attr.decrit);  

這樣的代碼，中間加個字段，就會徹底亂了。

11.推送數據要儘可能縮減，一般一個功能的所有數據在登陸的時候推一次，以後更新某個字段才逐個字段推送更新。

12.聲明變量的時候順手初始化一下。

13.循環用的迭代器，若是是後面沒有使用到，就應當放到循環內部。不一樣循環不要共用迭代器。

14.配置文件仍是服務端來設計，策劃只是給建議和參考。咱們要充分考慮策劃的命名，絕大部分是不能直接使用的，一般口頭說的是一個名稱，寫到文檔又是一個，等上線後又是一個命名。若是不理想，還會改不少次。並且，一個名稱可能會改掉，用在其餘系統上面。這個時候就很是混亂了。

15.要考慮卡頓的問題。出現卡通常能夠分爲幾種狀況：

（1）玩家實在是太多，如今的行業狀況，幾乎不可能出現了，只有在遊戲後期，不少個服合成一個服纔會出現。可是這樣的玩家，在線的仍是不多的。因此平時通常不考慮。

（2）功能業務上設計有問題，讓玩家同一個很是短的時間段內必須作某件事情。例如設個5分鐘的運鏢3倍時間，這個時刻一到，全部玩家都在運鏢。碰到這種問題，要主動跟策劃商量，讓其認識到可能發生的狀況。這種錯誤很很明顯，可能天天到這個時間段，就會卡，也會有不少玩家反映。可是修改的目標也很明確。

（3）代碼邏輯問題，最容易出現的就是for循環。例如300級的坐騎，若是每級的屬性都是獨立計算，每次訪問，升級，甚至走一步都檢測一下。還得循環幾百次，累計起來的計算量會很大的。這種錯誤很是隱蔽，多少次循環纔算是有問題？這個沒法下定論，可是計算量確定是累計在那裏，這個功能累積一下，那個功能累積一下，整個系統就會很卡。這種卡是無時無刻，偶爾爆發一下徹底動不了，難以尋找，也不知服務端仍是客戶端的問題。一般都是伴隨着遊戲的整個生命週期。幾乎沒法根治，只能在設計和編寫代碼的時候有意識地避免。

16.獨立的功能儘可能獨立管理本身的數據，若是使用了一些寫死的數據，也要改爲常量。

17.除數必須檢測是否爲0，不論是否從業務上看起來不可能爲0.

18.機率的問題，C++隨機數最大值是30000多。另外，涉及到戰鬥和屬性相關的，統一使用1000，用常量FIGHT_RATING。其餘的沒什麼特殊要求用100就好了。

19. 在一段程序裏面，對於一些檢測判斷，比較容易return或者拋異常的，應該放在前面。變量儘量放到要用的時候才聲明。

20. 儘可能不要把int當bool來使用。代碼有變更以後很容易出錯，並且就算用int來存放結果，不少時候0不必定表明錯誤。

21.同一個功能的配置，建議放在同一個表裏面。固然，東西不多的小功能，能夠放到t_const裏面。可是也有不少功能，可能內容很散，有多種配置，並且數據量不是很大，能夠放到同一張表裏面。

一般用這種格式來寫，可是要注意幾點：

    1.必須有desc字段，寫清楚每一個字段的意義，上面的還不是很詳細。應該這樣：

    type類型value1：階數，value2：星數，value3：exp，value4：屬性id

    2.在代碼裏面，要寫本身功能的結構，不能直接使用value1，value2，value3.在loadConfig函數裏面就應該轉換完成。這種通用表格的內容不該該出如今業務層的代碼裏面。

 

22.通常狀況下，只有接口訪問纔可以直接拋異常，其餘地方拋異常會出問題的，例如登陸。

23. 對於某些屬性，過了某個時間失效的狀況。設個定時器，到了這個時間點，就把全部的都改掉，這是策劃的思想。咱們一般在使用到的時候檢測一下是否失效了就好了。