Simplify Code

Simplifying your code is a way to make it more readable, faster and better.

Loops in Tables
Instead of using loops with tables to identify a value, you can use the index operator to get an object by it's placement position: -- We want r to be object 3, t is a constant array of objects k and their id's. t = {{ id = 0, k = "object_1"}, {id = 1, k = "object_2"}, ...} r = nil -- Worse: for j = 1, 10 do   if (t[j].id == 3) then r = t[j].k    end end -- Better: for j = 1, 10 do    if (t[j].id == 3) then r = t[j].k       -- Exiting a for loop is always better than running through it. break end end -- Best: (No for loop) r = t[3].k

Unnecessary calculations
When drawing a rect, some calculations can be removed: -- Bad: rect(40 + WIDTH*.3, 30, WIDTH - WIDTH*.3 - 40*2 + 10, HEIGHT-30*2) -- Good (less operations = faster; space between operations = beauty of code): rect(40 + WIDTH * .3, 30, WIDTH * .7 - 70, HEIGHT - 60) -- Source Code: Application by Anatoly (not shared)

Multiplications are faster than divisions.
x * 0.5         is faster than    x / 2 x * x           is faster than    x ^ 2    and    math.pow(x, 2) x * ( 1 / 3 )   is faster than    x / 3 "" .. 5         is faster than    tostring(5)

Locals are faster than globals
If you use a function like math.sin many times in a for loop, creating a local sin = math.sin (without the brackets) can speed up the function call

Performance

 * Meshes are faster than a lot of rects.

Initialisation of Tables
If you have a table with a predefined length, it will be faster than a generator. // Slow local a = {} a[1] = 5 a[2] = 7 a[3] = 1 // Fast: Length of b is predefined. local b = {true, true, true} b[1] = 5 b[2] = 7 b[3] = 1

Make Code Structure Understandable
An understandable code structure is very important when sharing your code with others, or making it open source. Some important factors that play a role, are:
 * Code Indent. Inside every for loops, if statements and functions, indent the children code by 4 spaces, to make it more understandable. It helps to have a better overview over your code.
 * Use the corresponding tabs. Do not put all your code in one tab. Be free to use as many tabs as you need to, do not put all 20 classes on one page (if these are large classes).
 * Comment enough. Commenting your code (or disabling it) on parts that are hard to figure out is important so you later now, what you have done. Explain what's going on.

It is also important not to delete all the code that does not work right now. In the end, it may play a role.
 * Always keep a copy of your project. While this isn't really for the structure, it's great to have a 'git' copy of your code. Since Codea has no Git initialised per default, having a copy of your code (in Codea or on Github) is good for the case when all data is lost.
 * Name your variables based on what they do; like players, configuration instead of p and c, to have a better understanding of the code structure.

Read More

 * http://www.lua.org/gems/sample.pdf