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"'

• 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

--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)

-- 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",
}

-- bad
superpower = getSuperpower()

-- good
local superpower = getSuperpower()

-- good
self.superpower = getSuperpower()

• 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

-- bad
local whatever = "sure";
a = 1; b = 2

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

• 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)

-- okay
local message = "Hello, "..user.."! This is your day # "..day.." in our platform!"

-- 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

-- 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)

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