Lua代碼編寫規範

開發中，大量使用lua，暫時根據當前情況，總結相對而言較好的規範，在多人協做中能夠更好的開發、交流。
 
介紹 

該文檔旨在爲使用lua編寫應用程序創建編碼指南。 
制訂編碼規範的目的： 

• 統一編碼標準，通用，提升開發效率； 
• 使代碼通俗易懂，易於維護。 

切記：善用調試器。 

1、 命名慣例 

1．全部lua文件命名時使用小寫字母、下劃線

2．類名、變量名儘量使用有意義的英文，類名使用帕斯卡命名法，變量名使用駱駝式命名法 

3．常量、消息號定義時用大寫，單詞間 _ 分割  eg:KIND_PET_FOOD

4．枚舉值定義時 加前綴 enum_ 

5. 函數名使用駱駝式命名法

注：

駱駝式命名法：第一個單字以小寫字母開始；第二個單字的首字母大寫或每個單字的首字母都採用大寫字母

帕斯卡命名法：和駱駝命名法很像，只有一點區別，就是首字母要大寫。(單字之間不以空格斷開或鏈接號)

2、 文件組織 

1. 文件開頭加上此文件的功能、職責的簡要描述； 

以下：

　　-- Author: Feng

　　-- Date: XXXX-XX-XX

　　-- 功能描述

 

每一個文件都加module 限定詞； 導入的模塊都加 local 限定詞；或者使用(module(..., package.seeall))，這樣便於進行熱更新

 

2. 全部提供外部函數都加以下格式的註釋。 

例如： 

--此函數檢測是否能夠從A(oldx, oldy)點走到B點（newx, newy） 

--@param oldx 當前所在點x 

--@param oldy 當前所在點y 

--@param newx 目標點x 

--@param newy 目標點y 

--@return 若能夠到達，返回true；不然返回false 

function Object:checkBar(oldx, oldy, newx, newy) 

… 

end 

 

3. 函數與函數間、以及一些定義之間加上空行。  

4. 函數內的臨時變量、文件內的局部函數都加上 local 限定詞 

5. 函數的行數過長（大於100行）時，儘可能拆分爲多個子函數；函數中一些晦澀的部分，必定要加上註釋。 

6. 短小的註釋使用 --； 較長的註釋使用 --[[ ]] 

7. assert函數開銷不小，請慎用。 

8. Lua類設計時，用元表來實現oop。 

不要直接增長函數成員，由於直接增長函數成員會致使內存增長而且在jit下執行效率和用元表方式無差別。 

9. 文件使用UTF8格式

3、 分隔和縮進 

1. 使用空行 

  在下述狀況下使用單行的空白行來分隔： 

    1）在方法之間 

    2）在方法內部代碼的邏輯段落小節之間 

    3）在註釋行以前 

  註釋以前增長一行或者多行空行。 

 

2. 使用空格符 

  除正常的成分之間以空格符分隔名（如數據類型和變量名之間），在下述狀況下也應使用一個空格符來分隔： 

    1）運算符和運算符之間，如： c = a + b； 

    2）在參數列表中的逗號後面，如： 

    function m1(year, month) 

    end 

    3) 在for語句時，如： 

    for k, v in pairs(t) do 

    end 

    4)在下列狀況下不要使用空格。 

    例如： 

    函數定義時： 

    function test1(a) 

    end 

    不要這樣： 

    function test1( a ) 

    end 

函數調用時： 

    test1(3) 

不要這樣： 

    test1( 3 ) 

    不要如此的緣由在於： 

        a).容易忘記相關空格，致使風格不統一，這樣還不如不加； 

        b).lua解析語法時是採用空格等分割來解析的，某些狀況下，若不當心加空格會致使非預期的結果。 

3. 使用換行符 

不建議在一行中寫多條語句，一條語句的長度通常超過了80個字符時，應該換行 

4. 使用小括號 

可使用小括號來強行規定運算順序 

5. 使用縮進 

在下述狀況下應用縮進 

1）類中的成分 

2）方法體或語句塊中的成分 

3）換行時的非起始行 

縮減量通常爲在上一級成分的基礎上跑到下一個製表位 

 

4、 代碼建議： 

1． 代碼中使用的一些函數儘量在文件開頭或者當前局部環境中加local前綴從新定義下。 

例如： 

local assert = assert  

2.  儘可能減小表中的成員是另外一個表的引用。 考慮lua的垃圾收集機制、內存泄露等。 

3． 高級特性儘量不用 

4． 寫代碼時儘量寫的簡單，考慮性能時先作好推斷，看看能提高多少，增長的複雜度以及形成的代碼晦澀有多嚴重，而後再決定如何作 

5． 加載的xml數據表，儘量的作好數據校驗，若校驗失敗，要出發斷言，使服務器沒法啓動；不要等出錯時，回過頭來檢查是數據表問題仍是邏輯問題。 

6． 出錯時，記錄好錯誤日誌。 

有的函數開銷比較大，而調用的頻率很低，那麼能夠不對他作優化； 

反之，有的函數開銷較小，可是調用的頻率很高，從如何下降調用頻率以及減小函數開銷兩個角度去思考，而後定下優化方案 

提交代碼以前，去掉或者註釋掉無關的代碼； 測試下保證服務器能夠正確啓動。
---------------------
版權聲明：本文爲CSDN博主「熱血楓葉」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處連接及本聲明。
原文連接：https://blog.csdn.net/rexuefengye/article/details/47029339