Code preferences

[GVovkiv]

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

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
adventure = 2
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

[GVovkiv]

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
adventure = 2
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]

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.

[zorg]

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

[Gunroar:Cannon()]

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

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

[applebappu]

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

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.

How about classes?

[applebappu]

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 cloned = loadstring(dumped)
		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]

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.