4.7 KiB
Comments
- Put no space after
--
for commented out code - Put one space after
--
for actual comments
Example:
--print("foo")
print(bar) -- Prints a bar
- Use
-->
to signal output or return values
Example:
print(2 * 2) --> 4
return h * w --> area
- Use ldoc to document functionality
Example:
--- Foos a Bar
function foo(bar)
- Use
--
for comments that apply to the entire line - Use
--[[]]
for comments that apply to single elements of a line
Example:
local x, y -- coordinates
local h --[[height]], r --[[radius]]
- Use
--[[]]
comments to comment out items from a list - Include separators in the comment (or not) according to the rules in the table / sequence section
Example:
print("Hello", "World"--[[, "foo", "bar"]])
local elements = { foo, --[[bar,]] }
- Prefer splitting lines to using several comments per line
Example:
local r -- radius
local h -- height
- Always close multi-line comments with
--]]
Example:
--[[
this code
does stuff
--]]
- Always close inline ranged comments with
]]
Example:
local foo --[[Foo]], bar --[[Bar]]
Variables
- Use
do ... end
blocks to limit the scope of a local variables - Put the
do
keyword on the same line as a related declaration
Example:
local foo do
local bar = 2 + 2
foo = bar * 2
end
Tables
Spacing
- Either use one space after
{
and one before}
- Or neither of them
- Put spaces after the separator (if at all), never before
Example:
local outer = { {"inner",1}, {"inner",2}, }
- Either put the entire table on one line
- Or don't put any items on the same line as the curly braces.
- Indent the items of the table
Example:
local oneline = {'hello', 'world',}
lcoal multiline = {
'hello',
'world',
}
Sequence
- Use commas (
,
) to separate order-dependant items (list) - Use semicolons (
;
) to separate order-independant items (set)
Example:
local ingredients = { "eggs"; "flour"; "milk"; }
local steps = { "mix", "fry", }
- Put a separator after the last element if more can logically follow
- Put no separator after the last element if none should logically follow
- Put no separator after the last element if external conditions must change for an additional item to be inserted.
Example:
local color = { 0xff, 0x20, 0x40 }
local line = { {0, 0}, {0, 20}, {20, 20}, }
Map
- Place key-value pairs after the sequence
- Put a semantic separator after the last element as with pure sequences for open-ended sequences
- Or use a different separator to signal that no items should be added
Example:
local pancakes = {
'mix', 'fry';
ingredients = { 'milk'; 'eggs'; 'flour' };
}
local pancakes = {
'milk'; 'eggs'; 'flour',
steps = {'mix', 'fry'};
}
- Use commas if the elements follow some logical order
- Use semicolons otherwise
- Apply same rules as with sequnces for separator after last element
Example:
local point = {x=20, y=30}
local tasks = { monday = {'call steve'}, tuesday = {'fix kitchen door'}, }
local person = { name="John Doe"; age="Unknown" }
- Treat arbitrary integer keys as string keys
- Use square brackets for numbers acting as keys in a map
- Judge based on semantic meaning, not on technicalities
Example:
local ages = { [20]="John, Henry"; [21]="William"; }
local errors = { [1]="File not Found"; [2]="Permission Denied" }
Errors
- On error, functions should return
nil
+ error message - Whenever possible, an identifier should be passed as the third argument
Explanation:
nil
+ message is a widely used convention for returning errors in Lua.
However, error messages are not guaranteed to remain unchanged,
this they are poorly suited to identify an error programatically.
Thus it makes sense to pass a third value that can be used to identify an error
condition. This can be a numeric error code, a string or a unique table.
Example:
local function divide(dividend, divisor)
if divisor == 0 then
return nil, 'Attempting to divide by 0', 'division-by-0'
else
return dividend / divisor
end
end
- Libraries should never raise errors to the calling code.
Explanation:
Because error-handling mechanisms in Lua are very simple and there is no mechanism like 'rescue' blocks, errors are hard to deal with in section of code that require cleanup operations to keep state (be it internal or external) consistent.