Brighter Shores:Lua

Lua is a programming language that is integrated into the Brighter Shores Wiki with Scribunto. Lua source code is run from Modules in their own namespace, and invoked with {{#invoke:Module|function}}; this should be done with a wrapper template. For example, if we have a module named "foo", then we should have a template called "Template:Foo" consisting of {{#invoke:Foo|main}} to call the module, and use {{Foo}} to use the module on pages.

For certain complex templates, Lua runs many times more efficiently than standard wikitext. It can also perform operations not available otherwise in wikitext. Unlike JavaScript, it is available to all readers, and does not need to be enabled. It is also run during parsing, rather than after.

All templates and modules should have a /doc page with at least {{Documentation}} or {{No documentation}} on it.

For an introductory guide to using Lua on the wiki see Help:Editing/Lua guide.

Helpful tips[edit source]

In order to produce Lua code that is free from bugs and to do so efficiently there's a few habits you should adopt as they will save you a lot of headaches.

Use the debug console[edit source]

The debug console lets you test code while you're working on it. This saves you a lot of time. It also lets you avoid saving unecessary revisions just to see if your code is working. Instead you'll only be saving known working code after you're done with adding a feature. Don't wait too long though, in case your power or internet goes out.

You can test expressions such as:

= 2+2

which will return

as you'd expect.

You can also call into any function that is visible from outside. If you defined this function as part of for instance table p which you're then returning to Scribunto, you can call into this function from the debug console:

local p = {}

function p.calculate(num)
    return num + 2
end

return p

= p.calculate(3)

or

mw.log( p.calculate(3) )

yields

If this function were instead returning a table you could inspect it like so:

local p = {}

function p.calculate2(num)
    return { num + 1, num + 2}
end

return p

mw.logObject( p.calculate2(3) )

Sometimes you might not be interested in the output and only want to check if a function works. In the above example you could have used one of the following for that:

= #p.calculate2(3)

= type(p.calculate2(3))

Of course calling any Lua function from the outside, expects the function to only take one argument, the frame object, which we can't provide in the debug console, so we have to work around that. This is usually done by providing two entry-point functions, one which takes the frame object, grabs the arguments from it an passes it on to the real function like so:

local p = {}

function p.calculate(frame)
    local args = frame:getParent().args

    return p._calculate(args)
end

function p._calculate(args)
    local num = args[1]

    return num + 2
end

return p

Normal invocation of the module will use the p.calculate() function, but now you can debug the output from the real p._calculate() function in the debug console like so:

= p._calculate({3})

Validate all input parameters[edit source]

Make sure to check all the input parameters you get from the entry point function, and do so early on. Invalid or unexpected data will cause your program to crash or misbehave.

Don't repeat yourself (DRY)[edit source]

If your code has sections that look very similar there's a good chance it can be simplified. Always look for opportunities like this.

Keep it simple stupid (KISS)[edit source]

Don't make something complicated if it doesn't need to be. Simpler code is easier to maintain. For instance maybe if you re-organized your data, it becomes much easier to handle in your code. Also does the task at hand really need a Lua module? If the problem is simple enough maybe a template or a macro will work just as well.

Avoid deep nesting[edit source]

If you have too many levels of indented code, that's a sign you need to break out some code and put it into functions.

Comments[edit source]

Good commenting is basically describing what a chunk of code does, not how it works. Also do not comment every line, you should comment every function and every major block of code.