56 replies to this topic

[Ferdi265]

I follow most of these habits, especially the one about indenting my code (oCd seems to help with coding)

Also, a very important thing is to stay with your style. And when I adopt a function from somewhere else, it really bugs me when the coder uses a style different from mine. I then just HAVE to change his sometable[ Myvariable ]+5 statements to the (in my opinion) more visually pleasing someTable[myVariable] + 5

[airtonix]

I wonder if Lua has the equivilant of Pythons PEP8.

My contribution to this would be to say that any code that does not have unit tests is broken by design.

[theoriginalbit]

airtonix, on 28 March 2013 - 08:56 PM, said:

I wonder if Lua has the equivilant of Pythons PEP8.

My contribution to this would be to say that any code that does not have unit tests is broken by design.

http://lua-users.org/wiki/UnitTesting

[Dlcruz129]

One thing I see people doing a lot is:

gui = {
"/-------\",
"|		  |",
"\-------/",
}

And then iterating through the table and printing each index. While this isn't a bad habit, I find it much simpler to do:

print [[
/------------\
|				 |
\-------------/
]]

It's a lot shorter and really saves time.

EDIT: Meh, the code highlighting screwed up my boxes, but I think you get the point

[SuicidalSTDz]

Dlcruz129, on 11 April 2013 - 12:53 PM, said:

One thing I see people doing a lot is:

gui = {
"/-------\",
"|		  |",
"\-------/",
}

And then iterating through the table and printing each index. While this isn't a bad habit, I find it much simpler to do:

print [[
/------------\
|				 |
\-------------/
]]

It's a lot shorter and really saves time.

EDIT: Meh, the code highlighting screwed up my boxes, but I think you get the point

I would agree except in this case:

local w,h = term.getSize()
local foo = {
 {text = "+", col = colours.red, pos = math.random(1,w)},
 {text = "*", col = colours.blue, pos = math.random(1,w)},
 {text = "+", col = colours.orange, pos = math.random(1,w)}
}

for _,v in pairs(foo) do
 term.setTextColour(v.col)
 term.setCursorPos(v.pos,math.random(1,h))
 term.write(v.text)
end

Just saying

[Dlcruz129]

SuicidalSTDz, on 11 April 2013 - 03:42 PM, said:

Dlcruz129, on 11 April 2013 - 12:53 PM, said:

One thing I see people doing a lot is:

gui = {
"/-------\",
"|		  |",
"\-------/",
}

And then iterating through the table and printing each index. While this isn't a bad habit, I find it much simpler to do:

print [[
/------------\
|				 |
\-------------/
]]

It's a lot shorter and really saves time.

EDIT: Meh, the code highlighting screwed up my boxes, but I think you get the point

I would agree except in this case:

local w,h = term.getSize()
local foo = {
{text = "+", col = colours.red, pos = math.random(1,w)},
{text = "*", col = colours.blue, pos = math.random(1,w)},
{text = "+", col = colours.orange, pos = math.random(1,w)}
}

for _,v in pairs(foo) do
term.setTextColour(v.col)
term.setCursorPos(v.pos,math.random(1,h))
term.write(v.text)
end

Just saying

Yeah, but for simple single-color textboxes and whatnot, multi-line strings are the best way to go.

[airtonix]

I sometimes wish there was a unittest framework for computercraft, but considering how the testable outputs would involve an object moving around in 3d gamespace, I can imagine how large a task it would be to create such a framework.

[Bubba]

airtonix, on 14 July 2013 - 06:52 PM, said:

I sometimes wish there was a unittest framework for computercraft, but considering how the testable outputs would involve an object moving around in 3d gamespace, I can imagine how large a task it would be to create such a framework.

pcall should suit your needs for unittesting. Not exactly a unittest, but it would protect you from errors and would, at the same time, allow you to identify any bit of code that does not run.

[strayzer]

considered myself a proficient coder until i read this and realized i am guilty of every single habit. Another good practice that I would recommend is ALWAYS use functions and name them correctly.I often find that even with simple code i confuse myself trying to figure out which function does what as i have the terrible habit of naming them the letter that my finger is hovering over at the time.

[Engineer]

strayzer, on 20 July 2013 - 02:38 PM, said:

ALWAYS use functions

I very, very disagree. I see where you are coming from with naming them, but really only use functions when you need a piece of code several times. To name it I would do something like:

-- This is the "function's" name
term.write( "This is " )
local s = "doing"
term.write( "what this code is " .. s )

I suppose then you are sometimes doing things like:

local function p()
   local s = "Hi!"
   term.write( s )
end

local function r( name )
   p() -- The one and only call in the whole script
   term.write( name )
end

Of course using some more (complicated) code.
In my opinion it is bad practise, but thats me. I think this is better:

function pr( name )
    local s = "Hi!"
    term.write( s .. name )
end

[Pharap]

Engineer, on 20 July 2013 - 06:20 PM, said:

strayzer, on 20 July 2013 - 02:38 PM, said:

ALWAYS use functions

I very, very disagree. I see where you are coming from with naming them, but really only use functions when you need a piece of code several times. To name it I would do something like:

-- This is the "function's" name
term.write( "This is " )
local s = "doing"
term.write( "what this code is " .. s )

I suppose then you are sometimes doing things like:

local function p()
   local s = "Hi!"
   term.write( s )
end

local function r( name )
   p() -- The one and only call in the whole script
   term.write( name )
end

Of course using some more (complicated) code.
In my opinion it is bad practise, but thats me. I think this is better:

function pr( name )
	local s = "Hi!"
	term.write( s .. name )
end

Seeing this makes me think how sometimes good practise and optimisation are at odds.
Dunno why, just does

[Fifi]

Well, I think using functions even if not necessary is acceptable only when the code don't have to be 100% optimized and the code simplicity would extremly suffer when everything will be write in a single code block. Although I still prefer vertical separation and comments instead of faking the need for refactorization. It's not a good practice to make a function of everything.

[Bubba]

If by optimized, people mean short, I would have to disagree. To me, optimization is a combination of readability, number of operations, and ease of customization later on. In Lua especially, there is no reason to program only in one block of code for non-repetitive tasks simply because you may at one point want to make the task repetitive and functions make that extremely easy. Also, functions have essentially no effect on speed in CC Lua, and I rather doubt that they have much of effect in a regular Lua environment either.

[Pharap]

Bubba, on 21 July 2013 - 10:53 AM, said:

If by optimized, people mean short, I would have to disagree. To me, optimization is a combination of readability, number of operations, and ease of customization later on. In Lua especially, there is no reason to program only in one block of code for non-repetitive tasks simply because you may at one point want to make the task repetitive and functions make that extremely easy. Also, functions have essentially no effect on speed in CC Lua, and I rather doubt that they have much of effect in a regular Lua environment either.

By optimised I mean goes fast.
Short code does not mean optimised code.
Sometimes 4 really long lines of code can generate faster bytecode than 2 short lines.
How fast functions are depends on their setup, for example a vararg function is slower than an explicit params function, but using a vararg function can be faster than passing a table to a function depending on how much indexing is involved.
Generally functions aren't a problem though, they only start to become a problem when you start giving them upvalues (each upvalue adds about 2 instructions to the function.

JLua is a lot different to CLua, and I believe it does some JIT compiling, in which case it's impossible to say anything other than CLua almost always runs faster.

[Tjakka5]

W00T, I got perfect habits!

[willdude123]

Good tips- goes for all coding, not just CC

[theoriginalbit]

Bubba, on 21 July 2013 - 10:53 AM, said:

If by optimized, people mean short, I would have to disagree. To me, optimization is a combination of readability, number of operations, and ease of customization later on.

Agreed. yet at the same time disagreed... There are times where good readability can make a large negative impact on the performance of a program. I definitely agree that programs should be readable to an extent, however sometimes readability must be sacrificed slightly for a more optimal solution... Also I have found that in most cases more optimised code is in fact shorter, and mostly still nice and readable, so I can definitely understand peoples confusion/correlation between optimised and lines of code. Normally things like number of operations is the main aspect of optimised code. One last thing is readability cannot really go into the general criteria of optimised programming as, well, everyone is different. My idea of readable code I can guarantee would be very different to yours, or most other peoples... Most people have their own "flare" and programming style that is guaranteed that others will not find readable... This is the sole purpose behind development companies implementing and forcing their employees to use specific naming conventions, habits and practises...