Why use local variables?

[Eamonn]

I've been getting into ComputerCraft again, and on a lot of tutorials I've found they say "Use local variables". One person said it would just confuse me if he told me, and wouldn't. I've also seen people on the LÖVE forum on old threads say to use them as well. Why? I think they're faster to access, and it avoids name conflicts, but is there an important reason? Name conflicts have never happened to me.

I know why you shouldn't use them, but I don't know who you should use them over global variables. If they are faster to access, I'm sure it would be a tiny difference. Name conflicts: just name your variable something different and save time? Why type local in front of the variable "name", and then be able to say "name" later on but still have to type local in front of it, when you could reduce the number of characters you have to type by about 9? It doesn't make sense that these would be the only 2 reasons, there's got to be more.

So: Why use Local and not Global? Does it only apply to Lua, or should I use it in all programming languages such as C++, Java, Xtend, Python, etc?

[raidho36]

It's faster that way. Faster to execute that is. And no, the difference is of order of magnitude: accessing a local takes nowhere more than normal Lua VM cycle, whereas accessing a global takes extra 4 VM cycles per each global, and that's a lot. Also, yes, aids to keep the namespace clean, as they only visible within current chunk. When you'll get to write a project with thousands of variables, you'll see.

Lua is the only language I know that has any concept of "local" variable. It's there because Lua handles locals differently - stores them to program stack, which is in turn in order of several magnitudes faster to work with than memory heap. In other languages, the point of declaring variables within program blocks rather than globally is to avoid using extra memory when they're not actually used and to keep the namespace clean.

[Eamonn]

Ah, so for smaller projects it's not as noticeable, but it'll help in bigger programs more so? Thanks!

[raidho36]

You just should always use locals whenever it's possible, and if you have a global and you gonna use it more than a couple of times or so, you make a local copy of it.

[Plu]

Ah, so for smaller projects it's not as noticeable, but it'll help in bigger programs more so? Thanks!

Yeah. Once you get to a few thousand lines, it's going to be hard to remember all those variable names so you can just type something different, and you're going to be looking for a lot of weird bugs because you accidentally overwrote something completely unrelated.

For 99% of programs the reduction in the number of bugs is worth far more than the extra performance gains, although it never hurts to be more efficient as long as your readability isn't suffering for it.

[Robin]

More importantly: global variables have a tendency to make your code highly coupled. That means that your program is one big ball of messy stuff. Using local variables helps to keep different parts of your program separate. This makes your program easier to test and far easier to debug. If a highly coupled program breaks, the problem could be literally anywhere. In a more decoupled program, if the program errors in player.lua, in the function player.jump(), it is more likely that the problem is there, instead of background.lua or player.move_left() or something.

Even if global variables were faster than locals, local variables would still be preferable because of that.

[Roland_Yonaba]

Why? I think they're faster to access.

Indeed. And I'd like to say something about that.
See this reference on Lua-users wiki: local vs global (and even some of these links).
Something you can do by yourself to assess that, using luac:

The following translates in VM as:

Code: Select all

local var
var = (var or 0) + 1

Code: Select all

> luac -l -l testlocalvsglobal.lua
main <testlocalvsglobal.lua:0,0> (5 instructions, 20 bytes at 005E1920)
0+ params, 2 slots, 0 upvalues, 1 local, 2 constants, 0 functions
	1	[2]	TESTSET  	1 0 1
	2	[2]	JMP      	1	; to 4
	3	[2]	LOADK    	1 -1	; 0
	4	[2]	ADD      	0 1 -2	; - 1
	5	[2]	RETURN   	0 1

Where as the following generates much more code (7 instructions, as compared to 5 with the previous code):

Code: Select all

var = (var or 0) + 1

Code: Select all

> luac -l -l testlocalvsglobal.lua
main <testlocalvsglobal.lua:0,0> (7 instructions, 28 bytes at 00241920)
0+ params, 2 slots, 0 upvalues, 0 locals, 3 constants, 0 functions
	1	[1]	GETGLOBAL	0 -1	; var
	2	[1]	TEST     	0 0 1
	3	[1]	JMP      	1	; to 5
	4	[1]	LOADK    	0 -2	; 0
	5	[1]	ADD      	0 0 -3	; - 1
	6	[1]	SETGLOBAL	0 -1	; var
	7	[1]	RETURN   	0 1

Second point, you might also like this very informative paper (excerpt from LuaGems), on Lua performance tips. It addresses the local-vs-global debate.
I remember a very interesting thread we had on that.

[BlackBulletIV]

Ah, so for smaller projects it's not as noticeable, but it'll help in bigger programs more so? Thanks!

It's hard to predict whether a "smaller" project will end up becoming a big one. And the bigger a project gets, the more noticeable the performance detriments, and more importantly, the more difficult it will be to sift through the mess.

Unless you're making a 20 line throwout script, get in the habit of using local variables; it'll make life so much easier in the long run.

[Xgoff]

Unless you're making a 20 line throwout script, get in the habit of using local variables; it'll make life so much easier in the long run.

even in that case i still use locals purely out of habit

[BlackBulletIV]

even in that case i still use locals purely out of habit

It's a good habit to be in.

It's worth noting that you can use local variables in files as well, since files essentially operate the same as untitled functions.