Contact Us

CATEGORIES

Whoops…Nothing found

Try other keywords in your search

Control Lua Style Guide

 3 Minutes

 0 Likes

 131 Views

This style guides lists the coding conventions used in PIXERA Control. 

These are recommendations only, the style in this guide is not enforced for reviews. 


Indentation and formatting

  • Control Lua code should be indented with one tab (4 spaces).
    Which is also defined in the internal code editor.
for i, pkg in ipairs(packages) do
    for name, version in pairs(pkg) do
        if name == searched then
        	print(version)
       end
    end
end

Documentation

  • Comments should be set to describe why a function exists and what purpose it serves. It is not necessary to describe exactly how the function works, this should be clear from the names of the variables.

Action names

See Module Style Guide 


Variable names

  • Variables and function names should prefer lowerCamelCase but in some situations snake_case is also appropriate as there are sometimes variable names that are otherwise difficult to read
  • Make sure that variables are well named to ensure better readability.
-- bad
local t = Pixera.Timelines.getTimelines()
local C = function(Parameter)
    -- ...stuff...
end

-- good
local timlines = Pixera.Timelines.getTimelines()
local function thisIsMyFunciton(inputParameter)
    -- ...stuff...
end

-- good
local theseAreMyTimelines = Pixera.Timelines.getTimelines()
local function thisIsMyFunciton(inputParameter)
    -- ...stuff...
end

-- okay
local these_are_my_timelines = Pixera.Timelines.getTimelines()
local function do_that_thing()
    -- ...stuff...
end

 

  • Prefer using is_ when naming boolean functions:
-- bad
local function evil(alignment)
    return alignment < 100
end

-- good
local function isEvil(alignment)
    return alignment < 100
end

UPPER_CASE is to be used sparingly, with "constants" only.


Strings

  • Use "double quotes" for strings; use 'single quotes' when writing strings that contain double quotes.
local name = "Pixera"
local sentence = 'The name of the program is "Pixera"'

Function declaration syntax

  • Prefer function syntax over variable syntax. This helps differentiate between named and anonymous functions.
-- okay
local nope = function(name, options)
    -- ...stuff...
end

-- good
local function yup(name, options)
    -- ...stuff...
end

 

  • Perform validation early and return as early as possible.
-- bad
local function isGoodName(name, options, arg)
    local is_good = #name > 3
    is_good = is_good and #name < 30

    -- ...stuff...

    return isGood
end

-- good
local function isGoodName(name, options, args)
    if #name < 3 or #name > 30 then
        return false
    end

    -- ...stuff...

    return true
end
  • Empty returns at the end of code in actions are not necessary 
--okay
local res = os.date(self.timeFormatCode) 

if self.lastRes == nil then 
	self.lastRes = res 
	return
end

pixc.report(res)
return

--good
local res = os.date(self.timeFormatCode) 

if self.lastRes == nil then 
	self.lastRes = res 
	return
end

pixc.report(res)

 


Function calls

  • Even though Lua allows it, do not omit parenthesis for functions that take a unique string literal argument.
-- bad
local data = get_data"KRP"..tostring(area_number)
-- good
local data = get_data("KRP"..tostring(area_number))
local data = get_data("KRP")..tostring(area_number)

 

  • You should not omit parenthesis for functions that take a unique table argument on a single line. You may do so for table arguments that span several lines.
local an_instance = a_module.new {
    a_parameter = 42,
    another_parameter = "yay",
}

Variable declaration

  • Always use local to declare variables.
  • Use  self. to declare module wide variables.
  • Avoid the use of global variables, global variables are created in Lua by default without declaration.
-- bad
superpower = getSuperpower()

-- good
local superpower = getSuperpower()

-- good
self.superpower = getSuperpower()

Not doing so will result in global variables to avoid polluting the global namespace.

 

Conditional expressions

  • there are differences with if conditions when they query for nil than with some that only query the variable, can be helpful when you need to know the difference between false and nil.
if name ~= nil then
    -- enter this if name is any but not on nil
end

if name then
    -- enter this if name is any but not on nil or false
end

Blocks

  • Separate statements onto multiple lines. Do not use semicolons as statement terminators.
-- bad
local whatever = "sure";
a = 1; b = 2

-- good
local whatever = "sure"
a = 1
b = 2

 


Spacing

  • Use a space after --.
--bad
-- good

 

 
  • Always put a space after commas and between operators and assignment signs:
-- bad
local x = y*9
local numbers={1,2,3}
numbers={1 , 2 , 3}
numbers={1 ,2 ,3}
local strings = { "hello"
                , "Lua"
                , "world"
                }
dog.set( "attr",{
   age="1 year",
   breed="Bernese Mountain Dog"
})

-- good
local x = y * 9
local numbers = {1, 2, 3}
local strings = {
   "hello",
   "Lua",
   "world",
}
dog.set("attr", {
    age = "1 year",
    breed = "Bernese Mountain Dog",
})

 

  • Indent tables and functions according to the start of the line, not the construct:
-- bad
local my_table = {
                    "hello",
                    "world",
                 }
using_a_callback(x, function(...)
                       print("hello")
                    end)

-- good
local my_table = {
   "hello",
   "world",
}
using_a_callback(x, function(...)
    print("hello")
end)

 

  • The concatenation operator gets a pass for avoiding spaces:
-- okay
local message = "Hello, "..user.."! This is your day # "..day.." in our platform!"

 

  • No spaces after the name of a function in a declaration or in its arguments:
-- bad
local function hello ( name, language )
    -- code
end

-- good
local function hello(name, language)
    -- code
end

 

  • Add blank lines between functions:
-- bad
local function foo()
    -- code
end
local function bar()
    -- code
end

-- good
local function foo()
    -- code
end

local function bar()
    -- code
end

 

  • Avoid aligning variable declarations:
-- bad
local a               = 1
local long_identifier = 2

-- good
local a = 1
local long_identifier = 2

 

  • Alignment is occasionally useful when logical correspondence is to be highlighted:
-- okay
sys_command(form, UI_FORM_UPDATE_NODE, "a",      FORM_NODE_HIDDEN,  false)
sys_command(form, UI_FORM_UPDATE_NODE, "sample", FORM_NODE_VISIBLE, false)

Things to avoid

  • Avoid using the goto statement, it can lead to spaghetti code.
    In the past, programming languages didn't have while loops, if statements, etc., and programmers used goto to make up the logic of their programs. It leads to an unmaintainable mess.

 


Pixera 2.0.172 | 13. September 2024 | J.B.

Was this article helpful?