Xenharmonic Wiki

User:Ganaram inukshuk/Provisional style guide for Lua: Difference between revisions

← Older edit
VisualWikitext
Ganaram inukshuk (talk | contribs)
autopatrolled, emailconfirmed
6,211 edits
No edit summary
Ganaram inukshuk (talk | contribs)
autopatrolled, emailconfirmed
6,211 edits
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 2: Line 2:


Parts of it are adapted for use on the wiki, with details on specific conventions. If a specific convention is missing, fall back to that described in the Luarocks style guide.
Parts of it are adapted for use on the wiki, with details on specific conventions. If a specific convention is missing, fall back to that described in the Luarocks style guide.
== Provisional additions for version 2 ==
Consistency with param names, including spelling:
* Define all param names at the module level, not the template level
* Use snake_case for all param names throughout; anything remotely close to snake_case is normalized to snake_case
* "debug" and "nocat" are reserved for toggling categories; the use of "debug" this way has already been the standard


== Preliminaries ==
== Preliminaries ==
Line 10: Line 17:
=== Naming and declaring variables ===
=== Naming and declaring variables ===


Variable names should be short and descriptive, written <code>snake_case</code>. Exceptions to this include counter variables, like with <code>i</code> in for loops. Boolean variables are prefixed with <code>is_</code>. Constants are named using <code>TRAIN_CASE</code>.
Variable names should be short and descriptive, written in <code>snake_case</code>. Exceptions to this include counter variables, like with <code>i</code> in for loops. Boolean variables are prefixed with <code>is_</code> or <code>has_</code> wherever possible. Constants are named using <code>TRAIN_CASE</code>.


All variable declarations should start with <code>local</code>.
All variable declarations should start with <code>local</code>.
Line 48: Line 55:
=== Naming, declaring, and calling functions ===
=== Naming, declaring, and calling functions ===


As with variables, functions are named using <code>snake_case</code>. Functions that return a boolean variable are prefixed with <code>is_</code>''.''
As with variables, functions are named using <code>snake_case</code>. Functions that return a boolean variable are prefixed with <code>is_</code> or <code>has_</code>.


''tbd''
''tbd''
Line 102: Line 109:


The use of a wrapper and "main" function allows for a module to be used directly in another module or indirectly through its corresponding template. A module should only provide '''one''' wrapper for '''one''' template. If the "main" function is short enough, its code may be merged with the wrapper function.
The use of a wrapper and "main" function allows for a module to be used directly in another module or indirectly through its corresponding template. A module should only provide '''one''' wrapper for '''one''' template. If the "main" function is short enough, its code may be merged with the wrapper function.


A tester function may be added for testing purposes, which is itself a wrapper that also calls the "main" function. This allows it to be tested using the in-browser console by calling mw.logObject(p.tester()). Tester functions may be removed if the "main" function is determined to be functional under expected conditions.<syntaxhighlight lang="lua">-- "Main" function to be called by wrapper or another module
A tester function may be added for testing purposes, which is itself a wrapper that also calls the "main" function. This allows it to be tested using the in-browser console by calling mw.logObject(p.tester()). Tester functions may be removed if the "main" function is determined to be functional under expected conditions.<syntaxhighlight lang="lua">-- "Main" function to be called by wrapper or another module
Line 134: Line 139:
-- Usable by other modules
-- Usable by other modules


function p._clamp(arg1, arg2, arg3)
function p._call_me(arg1, arg2, arg3)
     -- Code goes here
     -- Code goes here
end
end
Line 145: Line 150:
-- Usable by templates with {{#invoke}}
-- Usable by templates with {{#invoke}}


function p.clamp(frame)
function p._call_me(frame)
     return p._clamp(frame.args["arg1"], frame.args["arg2"], frame.args["arg3"])
     return p._clamp(frame.args["arg1"], frame.args["arg2"], frame.args["arg3"])
end
end
Line 156: Line 161:
For code readability and code reusability within the module, the use of helper functions is recommended.
For code readability and code reusability within the module, the use of helper functions is recommended.


Ideally, helper functions should be nested within the calling function if those helpers only serve that function, but this rule may be disregarded for testing purposes. Nested functions have access to the variables and parameters of the outer function, so an equivalent nested function may require fewer parameters.<syntaxhighlight lang="lua">function some_function(args)
Ideally, helper functions should be nested within the calling function if those helpers only serve that function, but this rule may be disregarded for testing purposes, or for helper functions needed by more than one function. Nested functions have access to the variables and parameters of the outer function, so an equivalent nested function may require fewer parameters.<syntaxhighlight lang="lua">function p._call_me(args)
     -- Get args here
     -- Get args here
     local arg1 = args["Arg 1"]
     local arg1 = args["Arg 1"]
Line 168: Line 173:


==== What to pass into a "main" function ====
==== What to pass into a "main" function ====
For an underscore-prefixed "main" function, if its expected inputs is determined to be fixed (for example, no new features are expected to ever be added), the function may accept them individually.<syntaxhighlight lang="lua">
For an underscore-prefixed "main" function, if its expected inputs is determined to be fixed (for example, no new features are expected to ever be added), the function may accept them individually.<syntaxhighlight lang="lua">-- "Main" function to be called by wrapper or another module
-- "Main" function to be called by wrapper or another module
-- Function signature consists of three args and the return value (not shown)
function p._call_me(arg1, arg2, arg3)
function p._call_me(arg1, arg2, arg3)
     -- Code goes here
     -- Code goes here
end
end</syntaxhighlight>If there is large amounts of input, or if the number of inputs is not known, the function should have a single parameter that is a table of passed-in arguments. This allows for expansion of the template's inputs without making the function signature any larger.<syntaxhighlight lang="lua">
</syntaxhighlight>If there is large amounts of input, or if the number of inputs is not known, the function should have a single parameter that is a table of passed-in arguments.<syntaxhighlight lang="lua">
-- "Main" function to be called by wrapper or another module
-- "Main" function to be called by wrapper or another module
-- Function signature consists of one table and the output (not shown)
function p._call_me(args)
function p._call_me(args)
     -- Get args here
     -- Get args here
Line 184: Line 189:
end
end
</syntaxhighlight>
</syntaxhighlight>
==== What to get out of a function ====
Most functions should return something (a value, a string, a table, or more than one of those things), with the exception of functions that change the contents of a table. Modules that implement templates typically return a string that represents something that can be interpreted as wikitext. Guidance on how to create such strings is explained in later sections.
=== Concatenating strings ===
=== Concatenating strings ===


Retrieved from "https://en.xen.wiki/w/User:Ganaram_inukshuk/Provisional_style_guide_for_Lua"