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