.profile/lua-style.md

4.7 KiB

Comments

  1. Put no space after -- for commented out code
  2. Put one space after -- for actual comments

Example:

--print("foo")
print(bar) -- Prints a bar
  1. Use --> to signal output or return values

Example:

print(2 * 2) --> 4
return h * w --> area
  1. Use ldoc to document functionality

Example:

--- Foos a Bar
function foo(bar)
  1. Use -- for comments that apply to the entire line
  2. Use --[[]] for comments that apply to single elements of a line

Example:

local x, y -- coordinates
local h --[[height]], r --[[radius]]
  1. Use --[[]] comments to comment out items from a list

  2. Include separators in the comment (or not) according to the rules in the table / sequence section

    print("Hello", "World"--, "foo", "bar") local elements = { foo, --bar, }

  3. Prefer splitting lines to using several comments per line

Example:

local r -- radius
local h -- height
  1. Always close multi-line comments with --]]

Example:

--[[
	this code
	does stuff
--]]
  1. Always close inline ranged comments with ]]

Example:

local foo --[[Foo]], bar --[[Bar]]

Variables

  1. Use do ... end blocks to limit the scope of a local variables
  2. 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

  1. Either use one space after { and one before }
  2. Or neither of them
  3. Put spaces after the separator (if at all), never before

Example:

local outer = { {"inner",1}, {"inner",2}, }
  1. Either put the entire table on one line
  2. Or don't put any items on the same line as the curly braces.
  3. Indent the items of the table

Example:

local oneline = {'hello', 'world',}
lcoal multiline = {
	'hello',
	'world',
}

Sequence

  1. Use commas (,) to separate order-dependant items (list)
  2. Use semicolons (;) to separate order-independant items (set)

Example:

local ingredients = { "eggs"; "flour"; "milk"; }
local steps = { "mix", "fry", }
  1. Put a separator after the last element if more can logically follow
  2. Put no separator after the last element if none should logically follow
  3. 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

  1. Place key-value pairs after the sequence
  2. Put a semantic separator after the last element as with pure sequences for open-ended sequences
  3. 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'};
}
  1. Use commas if the elements follow some logical order
  2. Use semicolons otherwise
  3. 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" }
  1. Treat arbitrary integer keys as string keys
  2. Use square brackets for numbers acting as keys in a map
  3. 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

  1. On error, functions should return nil + error message
  2. 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
  1. 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.