xref: /freebsd/share/man/man9/style.lua.9 (revision 05248206f720394d95c2a7475429311df670a2e9)
1.\"-
2.\" SPDX-License-Identifier: BSD-2-Clause
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.Dd February 25, 2018
28.Dt STYLE.LUA 9
29.Os
30.Sh NAME
31.Nm style.lua
32.Nd
33.Fx
34lua file style guide
35.Sh DESCRIPTION
36This file specifies the preferred style for lua source files in the
37.Fx
38source tree.
39Many of the style rules are implicit in the examples.
40Be careful to check the examples before assuming that
41.Nm
42is silent on an issue.
43.Pp
44The copyright header should be a series of single-line comments.
45Use the single-line comment style for every line in a multi-line comment.
46.Pp
47After any copyright header, there is a blank line, and the
48.Li $\&FreeBSD$
49comment for non-C/C++ source files.
50.Pp
51The preferred method of including other files and modules is with
52.Fn require name ,
53such as:
54.Bd -literal
55-- $FreeBSD$
56
57config = require("config");
58menu = require("menu");
59password = require("password");
60-- One blank line following the module require block
61.Ed
62.Pp
63.Fn include
64is generally avoided.
65.Pp
66Indentation and wrapping should match the guidelines provided by
67.Xr style 9 .
68Do note that it is ok to wrap much earlier than 80 columns if readability would
69otherwise suffer.
70.Pp
71Where possible,
72.Fn s:method ...
73is preferred to
74.Fn method s ... .
75This is applicable to objects with methods.
76String are a commonly-used example of objects with methods.
77.Pp
78Testing for
79.Va nil
80should be done explicitly, rather than as a boolean expression.
81Single-line conditional statements and loops should be avoided.
82.Pp
83.Ic local
84variables should be preferred to global variables in module scope.
85internal_underscores tend to be preferred for variable identifiers, while
86camelCase tends to be preferred for function identifiers.
87.Pp
88If a table definition spans multiple lines, then the final value in the table
89should include the optional terminating comma.
90For example:
91.Bd -literal
92-- No terminating comma needed for trivial table definitions
93local trivial_table = {1, 2, 3, 4}
94
95local complex_table = {
96	{
97		id = "foo",
98		func = foo_function, -- Trailing comma preferred
99	},
100	{
101		id = "bar",
102		func = bar_function,
103	},	-- Trailing comma preferred
104}
105.Ed
106.Pp
107This reduces the chance for errors to be introduced when modifying more complex
108tables.
109.Pp
110Multiple local variables should not be declared
111.Sy and
112initialized on a single line.
113Lines containing multiple variable declarations without initialization are ok.
114Lines containing multiple variable declarations initialized to a single function
115call returning a tuple with the same number of values is also ok.
116.Pp
117Initialization
118.Sy should
119be done at declaration time as appropriate.
120.Sh SEE ALSO
121.Xr style 9
122.Sh HISTORY
123This manual page is inspired from the same source as
124.Xr style 9
125manual page in
126.Fx .
127