使多余的标记可选
 |
||
|
使多余的标记可选 |
|
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 之间。你不必评估表达式来查看它们是否完整（即因为 eol ; 是可选的）。当然，可以添加括号以确保表达式完整，但这些也是可选的和多余的。--NDT
我不觉得更容易。
首先，在编写良好的 C/Pascal/Lua/... 中识别块并不困难，这要归功于缩进。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 的生命周期，如果它是一个大型对象并且 while 循环的其余部分非常耗时，这可能很有用。
如果 do 不能是可选的，那么唯一明确的可能性是必需的或禁止的；如果它被禁止，那么上面在 if 语句中提到的歧义是无法解决的。
C 通过要求条件表达式用 ( ) 括起来来解决在条件表达式之后跟语句的歧义，它使用 { 和 } 而不是 do/then 和 end；它还要求语句以 ; 结尾。最终，这几乎是一样的 - 相对吸引力将取决于你是否更喜欢标点符号而不是英文单词。