Lua代碼編寫規范


開發中,大量使用lua,暫時根據當前狀況,總結相對而言較好的規范,在多人協作中可以更好的開發、交流。
 
介紹 

該文檔旨在為使用lua編寫應用程序建立編碼指南。 
制訂編碼規范的目的: 

  • 統一編碼標准,通用,提高開發效率; 
  • 使代碼通俗易懂,易於維護。 


切記:善用調試器。 


一、 命名慣例 


1.所有lua文件命名時使用小寫字母、下划線

2.類名、變量名盡可能使用有意義的英文,類名使用帕斯卡命名法,變量名使用駱駝式命名法 

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

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

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

注:

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

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


二、 文件組織 


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格式


三、 分隔和縮進 


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)換行時的非起始行 

縮減量一般為在上一級成分的基礎上跑到下一個制表位 

 

四、 代碼建議: 


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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM