</header>
<div class="entry">
  
    <h1 id="目录"><a href="#目录" class="headerlink" title="目录"></a>目录</h1><ul>
  • 一、程序的版式
  • 二、命名规则
  • 三、文件组织
  • 三、分隔和缩进

    • 一、程序的版式

    Code is read much more often than it is written.

    Programming style is an art.

    1.1 空行

    • 需加空行：
      • 函数之间都要加空行；
      • 函数内部代码概念与逻辑之间，逻辑段落小节之间，都应该加空行；
      • 注释行之前。
    • 不加空行：
      • 在一个函数体内，逻揖上密切相关的语句之间不加空行；
      • 多行注释解释参数的时候，注释之间不加空行。

    1.2 空格

    • 需加空格：

      • “and“，”or“等关键字前后留一个空格，便于辨析；
      • 逗号”,“后面要留一个空格；
      • 赋值操作符、比较操作符、算术操作符如”=“、 “==“、”~=“、”>=“、”<=“、”>“、”<“、”+“、”-“、”*“、”/“、”%“、”^“,等二元操作符的前后应当加空格；
      • if、for、while等关键字之后如果要加左括号”(“，关键字与左括号之间应留一个空格，以突出关键字；

    • 不加空格：

      • 函数名之后不要留空格，紧跟左括号”(“；
      • 左括号”(“ 向后紧跟，紧跟处不留空格；
      • 右括号”)“、逗号”,“、分号”;“，向前紧跟，紧跟处不留空格；
      • 字符串连接符”..“前后不加空格；
      • “:“，”.“，”[“，”]“这类操作符前后不加空格；
    a > b and a or b           -- 良好的风格
a > b  and a or  b         -- 不良的风格

    local a, b, c, max         – 良好的风格
    
local a,b,c,max            – 不良的风格
    

    if a > b then              – 良好的风格
    
max = a
    
end
    
if a>b then max=a end      – 不良的风格
    

    data = dataTable[index]    – 良好的风格
    
data = dataTable [ index ] – 不良的风格
    

    function(posX, posY)       – 良好的风格
    
function (posX,posY)       – 不良的风格

    1.3 长行拆分

    • 代码行最大长度宜控制在70至80个字符以内。代码行不要过长，否则眼睛看不过来，也不便于打印；

    • 长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以便突出操作符）。

      -- 良好的风格
local newBuindingBtn = UI.newButton({             
    text = btnName,
    x = self.x,
    y = self.y,
    parent = self, 
    style = {
        normal = ResConfig.png.commonBtnBlue
    }
})

      – 不良的风格
      
local newBuindingBtn = UI.newButton({text = btnName,x = self.x,y = self.y,parent = self, style = {normal = ResConfig.png.commonBtnBlue}})
      


    -- 良好的风格
if veryLongerVariable1 >= veryLongerVariable2
    and veryLongerVariable3 <= veryLongerVariable5
    and veryLongerVariable4 <= veryLongerVariable6 then
    doo()
end

    – 不良的风格
    
if veryLongerVariable1 >= veryLongerVariable2 and veryLongerVariable3 <= veryLongerVariable5 and veryLongerVariable4 <= veryLongerVariable6 then
    
doo()
    
end

    1.4 使用缩进

    • 类中的成分
    • 方法体或语句块中的成分
    • 换行时的非起始行

    —

    二、命名规则

    三思而命名。

    2.1 共性规则

    • 命名应当直观且可拼读，可望文知意；
    • 标识符的长度应当符合“min-length && max-information”原则；
    • 采用英文单词或单词组合，英文单词不要复杂，但用词需准确，切忌使用汉语拼音命名；
    • 切勿为了避免命名过长而随意截取单词，以丢失可读性；
    • 所有命名都不要与－x已有的命名风格冲突，例如不要以CC，UI开头；

    2.2 文件命名

    • 所有Lua文件的命名时使用大驼峰法；
    • 根据文件的特性，一般以文件里的模块名或者类名作为同名文件名；

    • 确定命名前，请检查下，不要跟其他文件同名；

      CCArmature.lua    -- 不良的风格
UILayout.lua      -- 不良的风格

    2.3 类的命名

    • 所有类命名时使用大驼峰法；
    • 类名一般由”名词”或”多名词”组成，不要简写；

    • 根据类的特性，加上相关的后缀或者前缀；

      后缀：  
管理类  Manager
缓存类  Cache
控制类  Controller
模块    Module
网络类  Proxy

    2.4 变量命名

    • 通用规则

      • 使用 “名词” 或是 “形容词+名词” 命名；
      • 使用小驼峰法命名；
      • 为了可读性，尽量避免变量名中出现标号，如value1， value2；
      • 不要出现仅靠部分字母大小写区分的相似的变量；
      • 除非是局部变量功能等价全局变量，不然局部变量不要与已有的全局变量同名；

      • 尽量不要使用已有的类名作为变量名；

        local data          -- 良好的风格  
local oldData       -- 良好的风格 
local newData       -- 良好的风格     
local pairs = pairs -- 良好的风格

        local posx,posX     – 不良的风格
        
local btn1,btn2     – 不良的风格
        
local TABLE = {}    – 不良的风格
        
local uILabel       – 不良的风格

    • 类的成员变量

      • 类的成员变量以”self.”开头，以区分于局部变量；

        例如:
    function init()

            self.mainPanel = false -- 常用格式

    topPanel = false       -- 这样是全局变量，占用全局资源，而且难以区分于局部变量 
    ...
end

    • 全局变量

      • 全局变量使用双下划线(“__“)开头以及结尾，中间的命名以名词拼接，或”形容词＋名词”拼接，不同单词之间用（”_“）隔开；

        例如：
    __VERSION_CODE__ = "1.0.0.0"

    • 局部变量

      • M常用做模块里面表示模块本身

        module("MainGame.Module.IntegrationTest.MapModule",package.seeall)

        local M = class(SceneView,"MapScene")
        

        –数据的初始化
        
function M:init()
        
…
        
end
        

        …
        
return M

        • 引用进来的类或模块，用大驼峰法命名，引用路径统一带括号；

          module("MainGame.Module.IntegrationTest.MapModule",package.seeall)

          local M = class(SceneView,"MapScene")
          
local Surface = require("xx.xx")
          
local TestButtonPanel = require("xx")
          
…

    • 临时变量

      • 常用下划线”_”作为可以忽略的变量

        for _,v in ipairs(t) do print(v) end

        • i,k,v,t常做临时变量

          for k,v in pairs(t) ... end
for i,v in ipairs(t) ... end
mt.__newindex = function(t, k, v) ... end

    2.5 常量，事件名的命名

    • 常量，事件名所用单词均大写，单词用下划线(‘_‘)分割；

      例如：
    -- 常量 默认宽度
    LIST_DEFAULT_WIDTH = 100

      -- 事件 添加到场景
ADDED_TO_STAGE = getId()

    2.6 枚举的命名

    • 枚举名命名，与类名命名一致；

    • 枚举值命名，与常量，事件名的命名一致；

      例如：
    ControllerViewType = {
        SCENE = "SCENE",
        PANEL = "PANEL",
        POP =     "POP",
    }

    —

    ##三、文件组织

    3.1 文件描述

    • 文件开头加上此文件的简要功能作用描述；

      -- MapModule.lua
--Author:xx
--Email:xx@flamingo-inc.com
--20xx年x月x日 xx:xx
--Using:创建地图       
module("MainGame.Module.IntegrationTest.MapModule",package.seeall)
...

    3.2 文件中变量的定义

    • 如果在文件中需要多次使用的某些导入文件，可以在文件开头用局部变量存储导入信息，而不是在每次使用的时候都重新导入一次；

      例如:
    ...
    local Surface = require("xx.xx")
    local TestButtonPanel = require("xx")

      function M:xx()
    local testBtn = TestButtonPanel.newCC()
    ...
end

function M:yy()
    local panel = TestButtonPanel.newCC()
    local surface = Surface.newCC()
    ...
end

...

      3.3 类变量的定义

    • 类中的成员变量需要在init中先声明，并赋予初始值，不允许不声明直接使用；

    3.4 函数参数的定义

    • 所有函数的参数都用统一的params做参数，并加入如下格式的注释：

      --[[
    普通按钮 可缩放 scale9
    @param #string text 按钮名称
    @param #table style 按钮样式
]]
function UI.newButtonScale9(params)
   ...
end

    3.5 函数的定义规则

    • 函数的行数过长(大于 100 行)时,尽量拆分为多个子函数;
    • 函数中一些晦涩的部分,一定要加上注释；

    3.6 注释的使用

    • 短小的注释用–；
    • 长注释用–[[]]；

    —

    四、编码技巧

    4.1 应该尽量使用local变量而非global变量

    • 全局变量实际是放入全局表中，每次调用是用传入变量名作为key去获取，而local变量是直接通过lua的堆栈访问的；
    • 推荐写法
      • 在能用局部变量解决的地方，不要使用全局变量，这点很容易被忽略；
      • 多次重复使用的全局接口，可以用局部变量保存下再使用，这样做有两个好处：
        • 避免某些类型的全局变量被修改
        • 提高访问速度
    * 比如需要多重遍历操作一个大表：
写法1:
for k1,v1 in pairs(tbl) do
    for k2,v2 in pairs(v1) do
        ...    
    end
end

    写法2:
    
do
    
local pairs = pairs
    
for k1,v1 in pairs(tbl) do
    
for k2,v2 in pairs(v1) do
    
…
    
end
    
end
    
end
    

    – 由于pairs是一个全局变量应用的函数，所以写法2在这里有稍微效率上的提升，但要是单层遍历的没有这个效果了。
    

      

    • 

      当作常量来多次使用的全局变量可以存为局部变量使用
      
local playerName = Cache.playerCache.username
      
…
      
local function itemTemplate(data)
      
nameLabel:setText(playerName)
      
end
      

      • 

    

    local list = NewList.newCC(,{
    
itemTemplate = itemTemplate,
    
…
    
})

    ###4.2 临时变量的处理

    • 字符串的连接 ..

      由于字符串的管理机制，字符串在使用..连接时，会产生新的对象。由于lua在VM内对相同的string永远只保留一份唯一copy。

      例如:
local description ＝ ""
for i = 1,20 do
    description = description.."xxx"
end
-- 这样会生成21份string的copy，但实际上我们只需要最后那一份

      如果是轻量级的简单连接还是可以使用的，因为影响不大，但要是大量的类似拼接，推荐使用string.format

    • 类似于字符串的管理机制，表也存在类似的临时变量copy：

      函数传参数
function func({x,y})
    ...
end

      这种传参方式，每次都会生成一份copy，所以推荐以下的用法：

      function func(x,y)
    ...
end

      function func({posX = x, posY = y})
      
…
      
end

    ###4.3 利用逻辑运算的短路效应

    • and or 的返回值是表达式中的左值或者右值，可用来简化代码

      function foo(arg)
    arg = arg or "default"
    ...
end

      – 但要注意当赋值为bool值时候，容易出bug
      
a = a or true  – 错误的写法，当 a 明确写为 false 的时候，也会被改变成 true 。
      
a = a ~= false – 正确的写法，当 a 为 nil 的时候，被赋值为 true ；而 false 则不变。

    • 另外，巧妙使用 and or 还可以实现类似 C 语言中的 ?: 三元操作：

      function max(a,b)
    return a > b and a or b
end

      – 这里相当于 return (a > b) ? a : b;

    —

    五、代码建议

    5.1 代码的调试

    • 用Luastudio工具调试，代替Sublime调试Lua代码；

    5.2 复杂度和性能问题

    • 写代码时尽可能写的简单,考虑性能时先做好推断,看看能提升多少,增加的复杂度以及造成的代码晦涩有多严重,然后再决定如何做；

    5.3 函数的优化思考

    • 开销大的函数，调用次数低的话，可以不做优化；
    • 开销较小的函数，但调用频率很高，则从如何降低调用频率以及减少函数的开销两个角度去思考优化；

    5.4 提交代码的检查

    • 提交代码前，在svn commit中验证提交的代码，去掉或注释掉无关的代码，保证提交的代码无误；

    5.5 表结构的引用

    • 尽量减少表中的成员是另个表的引用；

    参考资料：

    [1] lua代码编写规范

    [2] Lua Style Guide

    [3] Lua 编程技巧

    [4] Lua 5.1 参考手册

    </div>