share/man/man9/style.lua.9

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