使冗余标记可选
 |
||
|
使冗余标记可选 |
|
if 语句后要求 'then'，在 while 和 for 语句后要求 'do'。这些都是完全冗余的，我建议将它们设为可选。它们会不必要地磨损我们的肌腱，并使代码更难阅读（眼睛更容易区分开头和结尾）。没有它们的代码更简洁易读。
local n = 10
if n > 5
for i=1,n
local x = n
while x > i
x = x - 1
io.write(x)
end
io.write('\n')
end
end
这是对 Lua 代码（LuaPowerPatches）的微小改动，提高了 Lua 的性能（虽然微不足道，但可证明），并且 100% 向后兼容。
我发现带有 do 和 then 的代码更容易阅读。阅读时更容易扫视。更容易看出块的开始和结束，并且你知道一个作用域在 do 和 end 之间。你不必评估表达式来判断它们是否完整（例如，因为行尾的 ; 是可选的）。当然，可以添加括号来确保表达式完整，但这些也是可选的，也是多余的。--NDT
我不觉得更容易。
首先，得益于缩进，在写得好的 C/Pascal/Lua/等语言中，识别块 hardly 难。Python 甚至将缩进作为块作用域的唯一指示符。它有效。
说实话，我很难相信你实际上会寻找 'then' 和 'do' 关键字来判断块的开始位置。我的眼睛会扫视代码的 左侧，仅通过缩进来匹配 'if'、'for' 和 'while' 语句与其对应的 'end' 语句。只有在我怀疑缩进误导的情况下，我才会开始扫视代码的 右侧。
当然，我不会在一行中写多个语句。也许如果我那样做，我将被迫养成忽略缩进并寻找分隔符来确定代码结构的习惯。但我更愿意一致地格式化代码，相信这样可以更容易识别。
因此，通过一致的格式化使块结构透明化，我们还能如何帮助快速识别？将语句的重要部分放在一行的开头和结尾，眼睛最容易看到的地方。选择好的变量名也适用同样的原则。
foobar1 foobar2优于
foo1bar foo2bar同样
if a if e优于
if a then if e then即使你不同意，并且认为这只是品味问题，我认为它没有理由不成为可选的。它对 Lua 没有任何损害。--EricTetz
我也觉得带有 "then" 标记的 Lua 代码并不更容易阅读。将其设为可选，没有任何正当理由不这样做。--DanHollis?
同意。如果我能像 Python 或 Ruby 那样写 'def' 而不是 'function'，我会很高兴，因为它更短。--YuraSokolov?
我发现 then 在有多个条件时显得简洁易读，例如
if
(cond1 == val1) and
(cond2 ~= val2) or
(cond3 <= val3)
then
-- code block
end
为了语法一致性，我投票支持保留它。但另一方面，你也可以说同样的话关于可选的括号 --SajberToffe?
then 在 Lua 4 中是完全多余的，但在语法被修改为允许以括号表达式开头的调用和赋值语句后，这种情况发生了改变；这次修改使得 ; 语句终止符只成为半可选的。以下代码如果没有 then 就无法编写，因为 ; 只能放在语句之后；没有 then 会造成歧义。
if x then (funcs[x] or default_func)() end
此外，do 在 for 或 while 语句中不能是**可选的**，因为块本身可能以 do 语句开始。
while x > 100 do
do
local y = f(x)
g(y)
h(y)
end
-- ...
end
上述代码限制了 y 的生命周期，如果 y 是一个大型对象而 while 循环的其余部分非常耗时，这可能会很有用。
如果 do 不能是可选的，那么唯一明确的可能性就是必需或禁止；如果它被禁止，那么在 if 语句中上述的歧义就无法解决。
C 通过要求将条件表达式用 ( ) 包围，并使用 { 和 } 代替 do/then 和 end 来解决在条件表达式后面跟一个语句的歧义问题；它还要求语句以 ; 结尾。最终，这基本上是各有利弊——相对吸引力取决于你更喜欢标点符号还是英语单词。