ifstatement, and 'do' following
forstatements. These are totally superfluous, and I propose they be made optional. They add unnecessary wear and tear on our tendons and make code harder to read (the eye is better at distinguishing beginnings and ends). Code is cleaner and easier to read without them:
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
It's a trivial change to the Lua code (LuaPowerPatches), increases Lua's performance (insignificantly, but provable), and is 100% backwards compatible.
I find it easier to read with the
thens. It scans more easily when you are reading it. It is easier to see where the blocks begin and end, and you know a scope is between a
end. You don't have to evaluate the expressions to see if they are complete (i.e. because the eol ; is optional). Of course brackets can be added to ensure expressions are complete, but then these are optional and superfluous too. --NDT
I don't find it easier.
First of all, recognizing blocks is hardly difficult in well-written C/Pascal/Lua/..., thanks to indentation. Python goes so far as to use indentation as the sole indicator of block scope. It works.
Truth be told, I find it hard believe that you actually look for 'then' and 'do' keywords to see where blocks begin. My eyes scan the left side of the code to determine block structure, matching up the 'if', 'for' and 'while' statements with their corresponding 'end' statements, purely by indentation. Only if there was a bug, something to make me suspect that the indentation as misleading, would I begin scanning the right side of the code.
Of course, I don't put multiple statements per line. Perhaps if I did, I would be forced to develop the habit of ignoring indentation and scanning for delimiters to figure out the structure of my code. But I prefer to format code consistently, believing that it makes recognition easier.
So, with block structure made transparent by consistent formatting, how else can we aid rapid recognition? By putting important parts of a statement at the beginning and end of a line, where the eye can see them most readily. The same principle applies to choosing good variable names:
foobar1 foobar2is better than:
if a if eis better than:
if a then if e thenEven if you disagree, and just want to chock it up to a matter of taste, I don't see why it shouldn't be made optional. I doesn't hurt Lua in the slightest. --EricTetz
I don't find lua code easier to read with the "then" token either. Make it optional, there's no legitimate reason not to. --DanHollis?
Agree. And I'd be happy if I could write 'def' instead of 'function' like in Python or Ruby - it is shorter. --YuraSokolov?
then clean and readable when having several conditions, e.g.
if (cond1 == val1) and (cond2 ~= val2) or (cond3 <= val3) then -- code block endFor the sake of consitent syntax I vote for leaving it in. But on the other hand, you could say the same about optional parenthesis --SajberToffe?
thenwas completely redundant in Lua 4, this changed when the grammar was changed to allow call and assignment statements to start with a parenthesized expression; this change made the
;statement terminator only semi-optional. The following could not be written without
;can only go after a statement; without the
thenit would be ambiguous:
if x then (funcs[x] or default_func)() end
do cannot be optional in a
while statement because the block could itself start with a
while x > 100 do do local y = f(x) g(y) h(y) end -- ... end
The above code limits the lifetime of
y which might be useful if it were a large object and the remainder of the
while loop was quite time-consuming.
do cannot be optional, then the only unambiguous possibilities are required or forbidden; if it is forbidden, then the ambiguity noted above in the
if statement is unresolvable.
C gets around the ambiguity of following the conditional expression with a statement by requiring that the conditional be surrounded by
( ) and it uses
} instead of
end; it also requires that statements be terminated with
;. In the end, it's pretty well a much of a muchness -- the relative appeal will depend on whether you prefer punctuation to English words or not.