Lua templating/Style guide

Note: this is a work in progress, please sit tight! You can take a look at my inspiration until this is finished:


 * Wikipedia:Lua style guide
 * PEP 0008 -- Style Guide for Python Code
 * The Ruby Style Guide
 * Airbnb JavaScript Style Guide

This article gives coding conventions for the creation and management of global Lua modules. For an introduction to Lua, please see our getting started guide.

What is this?
This article is a style guide, a set of standards and best practices created to help developers write better code. It encourages consistency between modules, which makes them easier to read, test, and maintain. That said, you should always use your best judgement when coding, and avoid the cargo cult.

Page structure
Each module (e.g. Module:Do something) should be accompanied by the following pages:

Escaping wikitext
Did you know that modules are parsed for wikitext? For example, this innocent-looking bit of code...

...will put its module in a bizarre category called ''&apos; .. name .. &apos;'' (quotes and all). To avoid this problem, always wrap your module in,  , or   (a.k.a.  ) tags.

Indentation
Use four spaces per indentation level. Pressing the "tab" key in Wikia's code editor results in four spaces, so the only way to get a tab character is to paste it from somewhere else.

Line length
Each line should be no longer than 80 characters. If a single line would be too long, you can split a large statement over multiple lines with a hanging indent that aligns with the opening delimiter. For if statements, the conditions should be placed on the next line with an extra level of indentation.

Semicolons
Don't use semicolons; they are completely optional in Lua, and only add visual clutter. As a corollary&mdash;use one expression per line.

Parallel assignment
Avoid parallel assignment when defining variables. It is allowed when all values are, when all values are returned from a single function, and when swapping variables. Parallel assignment is harder to read than separate assignment.

Operators
Place one space on either side of operators.

Bracketing characters
Do not place any space after,  , and  ; or before  ,  , and.

Commas
Place one space after a comma.

Functions
Place one space after the keyword, but do not place any after the function name.

Blank lines
Place an empty line after every  and   keyword, unless the next line has less indentation. Empty lines should also be used to break the module into logical "paragraphs."

Trailing whitespace
Remove extra whitespace from the end of each line.

Naming conventions
Define the entry method as simply unpacking the parameters from the frame, and then passing those through a function with the same name prefixed with a single underscore. This can be disregarded if the function is short and simple.

In the standard library, function names consisting of multiple words are simply put together (e.g. ). camelCase is the preferred way to name functions, in order to avoid potential garden path function names.

Whenever possible try to use  to invoke the function, e.g..

Module structure
Separate utility functions from the main p table, especially those functions that will not need to be directly accessible from templates or articles. If there are too many utility functions, consider creating a new meta-module and storing them there to reduce complexity.

Try not to have too many functions as the entry points for a module:

Function structure
Have descriptive function names that identify the action:

Invoked functions
Make sure invoked functions names are short, lower case, and descriptive to improve their usability.

Parameters
Avoid long lists of parameters (less than 7) for invoked functions, and consider using named parameters.