## Code preferences

General discussion about LÖVE, Lua, game development, puns, and unicorns.
GVovkiv
Party member
Posts: 179
Joined: Fri Jan 15, 2021 7:29 am
Contact:

### Code preferences

Just want to gather some statistics, what style for specific situation people prefer and why
1 Declaring multiple variables:

Code: Select all

local foo, bar = 1, 0

or

Code: Select all

local foo = 1
local bar = 0

2 Naming variables:

Code: Select all

local some_variable_1

or

Code: Select all

local someVariable1

3 Functions declaring:

Code: Select all

local function foo(bar) end

or

Code: Select all

local foo = function(bar) end

4 Short functions:

Code: Select all

local foo = function() return bar end

or

Code: Select all

local foo = function()
return bar
end

5 Table:

Code: Select all

local table = {foo, bar}

or

Code: Select all

local table = {
foo,
bar,
}

6 Multi-line commenting:

Code: Select all

--[[
foo bar
]]

or

Code: Select all

--
--foo bar
--

Gunroar:Cannon()
Party member
Posts: 519
Joined: Thu Dec 10, 2020 1:57 am

### Re: Code preferences

For me:
1) Variable declaration: depends.
If variables are related then

Code: Select all

x, y = 1, 0
width, height = 10, 10
--not related
donuts = 5
titan = false

2) Naming variable: for lua and others (C++, Java) I use someVariable for python I use some_variable. How about those who use "somevariable"

3) and 4) Functions: definitely

Code: Select all

local function foo()
return bar
end

Even if it's short, keeps things neat. If it's a quick test I use short one-lines but change them after. Though short functions can still be made to be neat.

5) Tables: Like 1, depends on whether they're related or not

Code: Select all

--not table, not to overwrite built in table variable,
--though I know it's just a test
local tab = {
x = 1, y = 5,
w = 4, h = 5,
titan = false,
fall = true
}

//short lists are in one line, but long multiple
local tab2 = { 1, 2, 3 }
local tab3 = {
1,
2,
...
100
} --though that seems not space efficient :P


Code: Select all

--[[
6)Long comment:
definitely this,
saves time,
though could be harder to keep track of
]]-- 
This is all just for me, btw
Why can't pirates code in lua? Because they spend to much time at C!

-It might look like nonsense but there's so much proof.
-Some more if you pls... .
It has to be real then, all that talk about the end .
-How to be saved
GVovkiv
Party member
Posts: 179
Joined: Fri Jan 15, 2021 7:29 am
Contact:

### Re: Code preferences

Gunroar:Cannon() wrote: Sun Aug 01, 2021 9:54 pm For me:
1) Variable declaration: depends.
If variables are related then

Code: Select all

x, y = 1, 0
width, height = 10, 10
--not related
donuts = 5
titan = false

2) Naming variable: for lua and others (C++, Java) I use someVariable for python I use some_variable. How about those who use "somevariable"

3) and 4) Functions: definitely

Code: Select all

local function foo()
return bar
end

Even if it's short, keeps things neat. If it's a quick test I use short one-lines but change them after. Though short functions can still be made to be neat.

5) Tables: Like 1, depends on whether they're related or not

Code: Select all

--not table, not to overwrite built in table variable,
--though I know it's just a test
local tab = {
x = 1, y = 5,
w = 4, h = 5,
titan = false,
fall = true
}

//short lists are in one line, but long multiple
local tab2 = { 1, 2, 3 }
local tab3 = {
1,
2,
...
100
} --though that seems not space efficient :P


Code: Select all

--[[
6)Long comment:
definitely this,
saves time,
though could be harder to keep track of
]]-- 
This is all just for me, btw
there is a special cauldron for these guys in hell whowrotevariableslikethat
darkfrei
Party member
Posts: 393
Joined: Sat Feb 08, 2020 11:09 pm

### Re: Code preferences

Code: Select all

local function foo (a, b, c)
return bar
end
And call this function as:

Code: Select all

foo (a, b, c)
And in other way if this function will be not more used.
Falling in LÖVE
I Löve Lua and Love2D
zorg
Party member
Posts: 3137
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: Code preferences

- locals on one line if 1. they're related to one another, and 2. if they fit into the line width limit of my choice.

- camelCase, but for classes, i use PascalCase.

- local function, just because the equivalent for that is actually this:

Code: Select all

local foo; foo = function() end
due to the other one dying if called recursively.

- one liner short functions, if they fit into the line width limit of my choice.

- one line if the table is used as an enumeration, same types and it fits the line width limit; in all other cases, each member on separate lines.

- --[[ --]] due to IDE toggleability.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Gunroar:Cannon()
Party member
Posts: 519
Joined: Thu Dec 10, 2020 1:57 am

### Re: Code preferences

zorg wrote: Mon Aug 02, 2021 5:46 am - camelCase, but for classes, i use PascalCase.
Woah, you even know what they're called, nice.
I think those who use camelCase should automatically use PascalCase for classes, but I guess you could be suprised.
GVovkiv wrote: Sun Aug 01, 2021 11:14 pm there is a special cauldron for these guys in hell whowrotevariableslikethat

Love2d kind of does it (keypressed, mousemoved )

I also use CAPSLOCK_UNDERSCORES for constants
Why can't pirates code in lua? Because they spend to much time at C!

-It might look like nonsense but there's so much proof.
-Some more if you pls... .
It has to be real then, all that talk about the end .
-How to be saved
applebappu
Prole
Posts: 37
Joined: Thu Jun 24, 2021 5:49 pm

### Re: Code preferences

I pretty much always separate out variable declarations, table items, function declarations, everything gets its own line. It just makes it way way easier to go back and parse later as the project gets larger. One-liners are fun as a challenge but it doesn't make a good workflow for me.

As for naming conventions, I like this_style for variables and ThisStyle for functions, with basically no variation ever. I don't tend to think in terms of constants vs. other kinds of variables, or methods vs. other kinds of functions. To me, a table is a table is a table.
Gunroar:Cannon()
Party member
Posts: 519
Joined: Thu Dec 10, 2020 1:57 am

### Re: Code preferences

applebappu wrote: Tue Aug 03, 2021 12:18 am I pretty much always separate out variable declarations, table items, function declarations, everything gets its own line. It just makes it way way easier to go back and parse later as the project gets larger. One-liners are fun as a challenge but it doesn't make a good workflow for me.

As for naming conventions, I like this_style for variables and ThisStyle for functions, with basically no variation ever. I don't tend to think in terms of constants vs. other kinds of variables, or methods vs. other kinds of functions. To me, a table is a table is a table.
Why can't pirates code in lua? Because they spend to much time at C!

-It might look like nonsense but there's so much proof.
-Some more if you pls... .
It has to be real then, all that talk about the end .
-How to be saved
applebappu
Prole
Posts: 37
Joined: Thu Jun 24, 2021 5:49 pm

### Re: Code preferences

Gunroar:Cannon() wrote: Tue Aug 03, 2021 9:37 am How about classes?
There are definitely times when it's useful to pair a table with some functions, particularly in game dev. When that situation arises, I try to keep it as flat as possible. I don't bother with encapsulation or any of that OOP nonsense (I solve the problem of shared state by doing a kind of high-level segregation in the form of modules, putting globals in a module, putting global functions in a module, etc. like, i'm not a crazy person, I just don't think segregating all state is the answer to the problem of shared state). Instead, I just fill a table with some functions, then code something to copy the table including those functions. Naming is just an initial capital, and I keep it to one word if possible. __index does the rest, and instantiation/construction is done by copying the table.

Here's the implementation I'm using in my current project. Note that I don't have any tables anywhere that go more than one level deep, so infinite recursion of copy isn't necessary.

Code: Select all

Entity = require "classes.Entity"
resources = require "modules.resources"

local tools = {
CopyTable = function(table)
local new_table = {}

for k, v in pairs(table) do
if type(v) == 'function' then
new_table[k] = tools.CloneFunction(v)
elseif type(v) == 'table' then
local sub_table = {}
for i,j in pairs(v) do
sub_table[i] = j
end
new_table[k] = sub_table
else
new_table[k] = v
end
end

setmetatable(new_table, table)
new_table.__index = table

return new_table
end,

CloneFunction = function(f)
local dumped = string.dump(f)
local i = 1

while true do
local name = debug.getupvalue(f, i)
if not name then
break
end
debug.upvaluejoin(cloned, i, f, i)
i = i + 1
end
return cloned
end

The way it works in actual practice is, I prepare a file where I keep all my mob data, and in there I call something like,

Code: Select all

slime = CopyTable(Entity)
...
set a bunch of attributes for slimes
...

fire_slime = CopyTable(slime)

And so on. Then in my actual spawning functions, I'm just calling other functions I've written that make reference to and create copies (instances, if you like) of these mob archetypes.
RamSam
Prole
Posts: 1
Joined: Sat Aug 07, 2021 7:27 pm

### Re: Code preferences

I am rather on more verbose side (maybe because of my Java's past). More lines is usually not a problem. So: one line - one declared variable for me.

### Who is online

Users browsing this forum: No registered users and 44 guests