Eight Good Coding Habits

Challenge.Accepted, on 30 October 2012 - 03:42 AM said:

1) Make comments on you own code. You're probably rolling your eyes right now thinking, "I know what my own code does. Why should I put comments on it?" And that's a valid question. Today I was looking back through some several month old code of mine and I didn't even know what the thing was supposed to do, let alone how I was supposed to utilize it. Figuring out its purpose would be nearly impossible without painfully going over every single function and testing them individually. So unless you want to rewrite your code every few months, or if you enjoy that painful 'decompiling' process, don't forget to comment as much as possible.

Challenge.Accepted, on 30 October 2012 - 03:42 AM said:

3) ALWAYS return something when you exit a function. I know it oftentimes seems unnecessary, but trust me when I say that debugging is a pain in the ass if you don't return something printable.

Challenge.Accepted, on 30 October 2012 - 03:42 AM said:

4) Keep your programming consistent. What I mean by that is don't sometimes use ipairs loops and other times use fori loops, unless of course the situation absolutely calls for that inconsistency. Things often become confusing when you mix and match your code.

Challenge.Accepted, on 30 October 2012 - 03:42 AM said:

6) Take breaks. If you're stuck on a problem, don't sit there and stare at it for ages trying to figure it out. Go grab a drink, eat some cereal, or play a game to take your mind off it for a while. When you come back, I can promise you that you'll be able to solve the problem much, much quicker than you would otherwise.

Challenge.Accepted, on 30 October 2012 - 03:42 AM said:

7) Program in a linear manner. When you program, do you find yourself jumping about from function to function, leaving some unfinished and others with errors in them? If you do, programming big programs will be extremely difficult. When you start a function, don't stop until you either finish it or you do away with it in favor of something else.

8) Program in chunks. This one is sort-of related to the previous point in that you should focus on certain aspects of a program and complete them before moving on to something else. For example, if you're making a mining program which sorts items based on ID, you might want to focus on the comparison of items first before moving on to navigation.

Lyqyd, on 31 October 2012 - 05:25 AM said:

Good stuff

Learning_inpaired, on 20 December 2012 - 03:07 PM said:

Bumbed!

Learning_inpaired, on 20 December 2012 - 03:06 PM said:

Bumbed!

Doyle3694, on 20 December 2012 - 11:25 PM said:

Ehrm…. How would that work, @sjkeegs ?

function gotoMyFurnace()
  -- find current  position
  -- grab the position of the furnace
  -- move x times in x direction

  -- move y times in y direction
  -- move z times in z direction

end

function getCurrentPosition()
  -- return current position
end


function getFurnacePosition()
  -- return furnace position
end
function getRelativeCoords(from, to)
  -- return relative coords
end
function moveBy(vec)
  -- move the turtle by vec (x, y, z)
end
function gotoMyFurnace()
  local currentPosition = getCurrentPosition()
  local furnacePosition = getFurnacePosition()
  local relativeCoords = getRelativeCoords(currentPosition, furnacePosition)
  moveBy(relativeCoords)
end

function getWaypoint(key)
  return waypoints[key]
end

function getCurrentPosition()
  -- gps.blah
  return { x=, y=, z=}
end


function getFurnacePosition()
return getWaypoint("furnace")
end

function getRelativeCoords(from, to)
  return {x=from.x-to.x, y=from.y-to.y, z=from.z-to.z}
end

function moveX()
  -- face x
turtle.forward()
end


function moveY()
  -- face y
turtle.forward()
end


function moveZ()
  -- face z
turtle.forward()
end

function moveBy(vec)
  for x=1, vec.x do moveX() end
  for x=1, vec.y do moveY() end
  for x=1, vec.z do moveZ() end
end

function gotoMyFurnace()
  local currentPosition = getCurrentPosition()
  local furnacePosition = getFurnacePosition()
  local relativeCoords = getRelativeCoords(currentPosition, furnacePosition)
  moveBy(relativeCoords)
end

Mikeemoo, on 21 December 2012 - 12:36 AM said:

Doyle3694, on 20 December 2012 - 11:25 PM said:

Ehrm…. How would that work, @sjkeegs ?

function gotoMyFurnace()
  -- find current  position
  -- grab the position of the furnace
  -- move x times in x direction

  -- move y times in y direction
  -- move z times in z direction

end

Evolves to.. ..etc..etc..

sjkeegs, on 20 December 2012 - 04:50 PM said:

–snip–
If you are programming something to do X, write the function that does that by just writing the comments.
–snip–

Grim Reaper, on 02 February 2013 - 12:24 PM said:

Something that I didn't see on this list, but I think should definitely be there is how pertinent variable and method names are in a script.

This rule kind of goes without saying, but a lot of people seem to write code which has very simple or just entirely irrelevant variable and function names (like 'x' or 'derp', for example) in their scripts. Using a relevant naming convention improves readability a ton and also helps the programmer to understand their own code better.

Also, a naming convention such as camel-cap for variable/function names is usually a good idea. However, naming conventions/styles are entirely up to the programmer.

local Mx,My=term.getSize()
local Cx,Cy=math.floor(Mx/2),math.floor(My/2)

PixelToast, on 02 February 2013 - 01:54 PM said:

when i cant think of a name i just find an achronym or short name for it
like this:

local Mx,My=term.getSize()
local Cx,Cy=math.floor(Mx/2),math.floor(My/2)

Max X,Max Y
Center X, Center Y

local tpe,id,data,dist=os.pullEvent()
local rData=infutil.decompress(data) or {}

local frequency = 0
local function receive()
    ...
    ...
    ...
    ...
    ...
    ...
end

local function escape()
    ...
    ...
    ...
    ...
    ...
    ...
end
local ingredients = {}

local function wheee()
    ...
    ...
    ...
    ...
    ...
    ...
end

-- insert 350 lines of other functions here


local function makeCake()
    ...
    ...
    ...
    ...
    ...
    ...
end

local function send(freq)
    ...
    ...
    ...
    ...
    ...
    ...
end

local function blam()
    ...
    ...
    ...
    ...
    ...
    ...
end
local cakes = {}

local cakes = {}
local ingredients = {}
local frequency = 0
local function makeCake()
    ...
    ...
    ...
    ...
    ...
    ...
end

local function send(freq)
    ...
    ...
    ...
    ...
    ...
    ...
end
local function receive()
    ...
    ...
    ...
    ...
    ...
    ...
end

local function escape()
    ...
    ...
    ...
    ...
    ...
    ...
end

local function wheee()
    ...
    ...
    ...
    ...
    ...
    ...
end
local function blam()
    ...
    ...
    ...
    ...
    ...
    ...
end
-- insert 350 lines of other functions here

baeshra, on 26 February 2013 - 03:12 PM said:

As a beginner in this field I know I have an odd coding style. How do most people organize their longer scripts? I tend to lay my code out under functions which allows me to re-order it easily, is there a better way to go about this?

shiphorns, on 05 March 2013 - 11:53 AM said:

That is to say, Lua was not designed for OOP, so the results of that experimentation tend to be ugly and cumbersome manipulation of metatables

shiphorns, on 05 March 2013 - 11:53 AM said:

You shouldn't go that route IMHO.

shiphorns, on 05 March 2013 - 11:53 AM said:

extract it into code libraries that you include with require

TheOriginalBIT, on 05 March 2013 - 12:37 PM said:

shiphorns, on 05 March 2013 - 11:53 AM said:

That is to say, Lua was not designed for OOP, so the results of that experimentation tend to be ugly and cumbersome manipulation of metatables

It actually WAS designed for OO, that is why we can manipulate metatables.

TheOriginalBIT, on 05 March 2013 - 12:37 PM said:

shiphorns, on 05 March 2013 - 11:53 AM said:

You shouldn't go that route IMHO.

I'm assuming you're another one of those people that prefers procedural programming over OO any day?

TheOriginalBIT, on 05 March 2013 - 12:37 PM said:

shiphorns, on 05 March 2013 - 11:53 AM said:

extract it into code libraries that you include with require

Doesn't exist, don't suggest things to newbies that don't exist, just causes headaches for us all later http://puu.sh/2cdch

shiphorns, on 06 March 2013 - 05:57 AM said:

No sir, I'm a game UI programmer by trade and I mostly work in C++ and AS 3.0. I'm an OOP guy through and through, and only use Lua when I have to.

Ugh, that is unfortunate. Hopefully the CC guys are working on this, but it does explain why we have so many programs here that are giant 1-file monoliths.

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.

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

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

Dlcruz129, on 11 April 2013 - 01: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 ;)/>

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

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

Dlcruz129, on 11 April 2013 - 01: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 :P/>

airtonix, on 14 July 2013 - 07: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.

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

ALWAYS use functions

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

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

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

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

strayzer, on 20 July 2013 - 03: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

Bubba, on 21 July 2013 - 11: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.

Bubba, on 21 July 2013 - 11: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.