Tips for the nonprofessional

The Defoldmine
#1

Here are some tips I’ve been learning over the past while learning Lua and Defold. These are not in any specific order, just written as I remember and come across them.

  • Generally, it’s good to begin your function with the first argument being “self”. That way, in the future, you won’t have to tediously go through every call of that function to make it work. This also helps when building the function. If you need to access “self”, it’s already set up for you.

  • Tables of variables and tables of tables are very handy if organized correctly. A horrendous amount of global variables can and WILL get you into a lot of collateral damage. “self” is a great way to do this.

  • Create little comments at the start of general functions, telling yourself and possibly others reading your code what the function will do. If you take a week break from programming, you might come back scratching your head when trying to figure out what your own functions do.

  • How do you eat an elephant? One bite at a time. Basically, don’t write enormous amounts of code and expect it to work perfectly. You’ll be better off writing a fraction of that chunk, fixing problems, and moving on to the next fraction.

  • Ask for help. I’ve personally asked a great number of questions. Many of my questions had simple fixes. Also, no one was ever judgmental or unhelpful and they would even point out other things in my code which solved future problems for me.

  • I’ve solved 99% of my problems using print(). print() would help me figure out where certain values went wrong, and how functions were being used. I’ve had to do a lot of cleanup though, so make sure to weed out the print()s that aren’t necessary once you’ve fixed the problem.

I hope to add more in the future. I’ll just leave this until more come to mind or when I run across them.

6 Likes
#2

Also: Give your functions and variables sensible names. And keep functions short. It’s better if a function does one thing and one thing only. Build behaviour from several small functions.

Amen! And remember pprint() for tables. A good practice may be to declare a log() function that by default is assigned the print() function. Then all you need to do is replace it with a no-op function to get a clean console. It’s still a function call but at least you’re not filling your console with debug prints. Like this:

local function nop() end

local log = print

function init(self)
	log("now I'm in init")
end

function update(self, dt)
	log("update", dt)
end

And when you don’t want any logging you instead do

local log = nop
4 Likes
#3

Oh yes. Print debugging is almost always sufficient. But wait for the integrated debugger, it will make things more pleasant.

8 Likes
#4

I wish I could like a comment multiple times! Print debugging is okay but it isn’t really optimal :slight_smile:

4 Likes
#5

The documentation about debugging should be updated! I learned about the new debugger combing through the forums :stuck_out_tongue_closed_eyes:. I even installed ZeroBrane and a couple of debugger extensions for Atom before learning about the new debugger.

That shiny new debugger is great! So far so good. Hopefully, features like watch and call stack will be added eventually. Right now though, it is already punching above its weight!

#6

@sicher is working on a new manual on debugging. We are also adding a new manual on in-depth application profiling which I believe will be really helpful for beginners and experts alike.

4 Likes
#7

Some pointers about how to get started with this ‘new debugger’? :slight_smile:

1 Like
#8

Left click in the gutter next to a line number to set a breakpoint. Select Run with Debugger from the menu. When your game hits the line with the breakpoint code execution stops and you can inspect the Lua stack and step through the code line by line.

4 Likes