1.\"- 2.\" Copyright (c) 2018 Kyle Evans <kevans@FreeBSD.org> 3.\" All rights reserved. 4.\" 5.\" Redistribution and use in source and binary forms, with or without 6.\" modification, are permitted provided that the following conditions 7.\" are met: 8.\" 1. Redistributions of source code must retain the above copyright 9.\" notice, this list of conditions and the following disclaimer. 10.\" 2. Redistributions in binary form must reproduce the above copyright 11.\" notice, this list of conditions and the following disclaimer in the 12.\" documentation and/or other materials provided with the distribution. 13.\" 14.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 15.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 16.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 17.\" ARE DISCLAIMED. IN NO EVENT SHALL [your name] OR CONTRIBUTORS BE LIABLE 18.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 19.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 20.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 21.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 22.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 23.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 24.\" SUCH DAMAGE. 25.\" 26.\" $FreeBSD$ 27.\" 28.Dd February 25, 2018 29.Dt STYLE.LUA 9 30.Os 31.Sh NAME 32.Nm style.lua 33.Nd 34.Fx 35lua file style guide 36.Sh DESCRIPTION 37This file specifies the preferred style for lua source files in the 38.Fx 39source tree. 40Many of the style rules are implicit in the examples. 41Be careful to check the examples before assuming that 42.Nm 43is silent on an issue. 44.Pp 45The copyright header should be a series of single-line comments. 46Use the single-line comment style for every line in a multi-line comment. 47.Pp 48After any copyright header, there is a blank line, and the 49.Li $\&FreeBSD$ 50comment for non-C/C++ source files. 51.Pp 52The preferred method of including other files and modules is with 53.Fn require name , 54such as: 55.Bd -literal 56-- $FreeBSD$ 57 58config = require("config"); 59menu = require("menu"); 60password = require("password"); 61-- One blank line following the module require block 62.Ed 63.Pp 64.Fn include 65is generally avoided. 66.Pp 67Indentation and wrapping should match the guidelines provided by 68.Xr style 9 . 69Do note that it is ok to wrap much earlier than 80 columns if readability would 70otherwise suffer. 71.Pp 72Where possible, 73.Fn s:method ... 74is preferred to 75.Fn method s ... . 76This is applicable to objects with methods. 77String are a commonly-used example of objects with methods. 78.Pp 79Testing for 80.Va nil 81should be done explicitly, rather than as a boolean expression. 82Single-line conditional statements and loops should be avoided. 83.Pp 84.Ic local 85variables should be preferred to global variables in module scope. 86internal_underscores tend to be preferred for variable identifiers, while 87camelCase tends to be preferred for function identifiers. 88.Pp 89If a table definition spans multiple lines, then the final value in the table 90should include the optional terminating comma. 91For example: 92.Bd -literal 93-- No terminating comma needed for trivial table definitions 94local trivial_table = {1, 2, 3, 4} 95 96local complex_table = { 97 { 98 id = "foo", 99 func = foo_function, -- Trailing comma preferred 100 }, 101 { 102 id = "bar", 103 func = bar_function, 104 }, -- Trailing comma preferred 105} 106.Ed 107.Pp 108This reduces the chance for errors to be introduced when modifying more complex 109tables. 110.Pp 111Multiple local variables should not be declared 112.Sy and 113initialized on a single line. 114Lines containing multiple variable declarations without initialization are ok. 115Lines containing multiple variable declarations initialized to a single function 116call returning a tuple with the same number of values is also ok. 117.Pp 118Initialization 119.Sy should 120be done at declaration time as appropriate. 121.Sh SEE ALSO 122.Xr style 9 123.Sh HISTORY 124This manual page is inspired from the same source as 125.Xr style 9 126manual page in 127.Fx . 128