跳转至

lua 工作中要注意的点

代码总则

可读性 逻辑坚实 易于维护 注释不嫌多 适当考虑效率 具体需求具体分析,少写万能代码

python之禅

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

优美胜于丑陋
明了胜于晦涩
简单胜于复杂
复杂胜于杂乱
扁平胜于嵌套
间隔胜于紧凑
可读性很重要
特例不足以特殊到违背这些原则
不要忽视错误,除非程序需要这样做
面对模棱两可,拒绝猜测
解决问题最直接的方法应该有一种,最好只有一种
可能这种方法一开始不够直接,因为你不是范罗苏姆
做也许好过不做,但不想就做还不如不做
如果方案难以描述明白,那么一定是个糟糕的方案
如果容易描述,那么可能是个好方案
命名空间是一种绝妙的理念,多加利用

代码风格

lua特性

其他

  • 注意代码风格统一,对齐是必须的,适度的换行和空行,保持整洁易读
  • 迭代list 的时候用ipairs, 迭代dict 的时候用pairs, 配表数据通常是个字典
  • 重复用的数据、表达式太长可以变量保存一下
  • 使用变量来省掉重复的计算和点操作

  • call 其他节点的时候要注意异步引发的问题。

  • 别在pairs迭代时删除table内容, 两种做法:

    1. for key in table.keys(table)
    2. 把要删除的key存起来, 迭代完统一删
  • 增加物品优先用add_new_item和add_item_list接口

  • 闭包的使用,lua中所有东西都是对象,闭包中引用的是对象不是值,注意值和对象地址的区别。