Lua code style guidelines

This is largely based on the Python style guide except for some indentation and language syntax differences. When in doubt, consult that guide.

Note that these are only guidelines for more readable code. In some (rare) cases they may result in less readable code. Use your best judgement.

Comments

 * Incorrect or outdated comments are worse than no comments.


 * Avoid inline comments, unless they're very short.

Good: Bad:
 * Write comments to clarify anything that may be confusing. Don't write comments that describe things that are obvious from the code.


 * Comments should follow English grammar rules, this means starting with a capital letter, using commas and apostrophes where appropriate, and ending with a period. The period may be omitted in single-sentence comments. If the first word of a comment is an identifier, its casing should not be changed. Check the spelling.


 * Comments should have a space between the comment characters and the first word.


 * Inline comments should be separated from the code by two spaces.


 * If you write comments for a documentation generation tool, write the comments in LuaDoc format.


 * Short multi-line comments should use the regular single-line comment style.


 * Long multi-line comments should use Lua's multi-line comment format with no leading characters except a  before the closer.

Lines, spaces, and indentation

 * Indentation is done with one tab per indentation level.


 * Lines are wrapped at 80 characters where possible, with a hard limit of 90. If you need more you're probably doing something wrong.

Continuation lines

 * Conditional expressions have continuation lines indented by two tabs.
 * Function arguments are indented by two tabs if multiple arguments are in a line, same for definition continuations.
 * If the function arguments contain a table, it's indented by one tab and if the arguments get own lines, it's indented like a table.
 * When strings don't fit into the line, you should add the string (changes) to the next line(s) indented by one tab.
 * When breaking around a binary operator you should break after the operator.

Empty lines

 * Use a single empty line to separate sections of long functions.


 * Use two empty lines to separate top-level functions and large tables.

Good: Bad:
 * Do not use a empty line after conditional, looping, or function opening statements.


 * Don't leave white-space at the end of lines.

Spaces
Good: Bad:
 * Spaces are not used around parenthesis, brackets, or curly braces.

Good: Bad:
 * Spaces are used after, but not before, commas and semicolons.

Good: Bad:
 * Spaces are used around binary operators with following exceptions:
 * There mustn't be spaces around the member access operator (".")
 * Spaces around the concatenation operator ("..") are optional.
 * In short one-line table definitions the spaces around the equals sign can be omitted.
 * When in-/decrementing a variable by 1, the spaces around the + and - operator can be omitted if you want to "get the neighbour" of something, e.g. when increasing some counter variable.

Good: Bad:
 * Use spaces to align related things, but don't go overboard:

Tables
Good: Bad:
 * Small tables may be placed on one line. Large tables have one entry per line, with the opening and closing braces on lines without items; and with a comma after the last item.


 * In list-style tables where each element is short multiple elements may be placed on each line.

Naming

 * Functions and variables should be named in , with the exception of constructor-like functions such as , which should use UpperCamelCase.


 * Don't invent compound words. Common words like   are okay, but mashes like   and   aren't.


 * Avoid leading and/or trailing underscores. They're ugly and can be hard to see.

Misc

 * Don't put multiple statements on the same line.

Good: Bad:
 * You can put conditionals / loops with small conditions and bodies on one line. This is discouraged for all but the smallest ones though.

Good: Bad:
 * Don't compare values explicitly to,  , or  , unless it's really needed.


 * Don't use unnecessary parenthesis unless they improve readability a lot.


 * Write function definitions of the form  instead of the lambda form , except when inserting functions in tables inline, where only the second form will work.


 * Avoid globals like the plague. The only globals that you should create are namespace tables &mdash; and even those will probably be phased out soon.


 * Don't let functions get too large. Maximum length depends on complexity; simple functions can be longer than complex functions.