Page 1 of 1
[Solved] Using local variables correctly?
Posted: Mon Dec 01, 2014 1:09 am
by AlexCalv
If I use local variables by just placing them at the top of my file like this:
Code: Select all
local number = 0
local vision = true
function love.load()
end
..blah blah...
Is that even using local vars right? I'm not entirely sure what the point of them is. I read that they were faster than globals, so I started putting variables that I only use in one specific file as locals at the very top outside of any functions. Does this way improve speed any or should I just stick to globals only. i don't see the difference between the two at all.
Re: Using local variables correctly?
Posted: Mon Dec 01, 2014 1:29 am
by iggyvolz
Technically, this isn't a löve-specific question, it applies to all Lua code.
Local variables are available only to the namespace that it is defined in (exception: local variables defined outside a function are accessible from a function), while global variables are available to all namespaces.
In english:
Code: Select all
-- FILE NAMED main.lua
print(foo) -- This will print nil because foo is not set
local foo = "bar" -- I am declaring foo locally - it can be accessed anywhere in the main.lua file
print(foo) -- This will print bar
function somecode()
print(foo) -- This will also print bar when I call the function
end
somecode() -- This will print bar
require "include" -- This will print nil because the local variable doesn't carry over to the other file.
-- NEW FILE named include.lua
print(foo) -- This will print nil when I require "include", because foo is not set here.
Code: Select all
-- FILE NAMED main.lua
print(foo) -- This will print nil because foo is not set
function somecode()
local foo = "bar" -- This sets foo only inside the function or any subfunction that I make of this
print(foo) -- This will print bar when I call the function
end
somecode() -- This will print nil because the local variable doesn't carry outside the file
require "include" -- This will print nil because the local variable doesn't carry over to the other file.
-- NEW FILE named include.lua
print(foo) -- This will print nil when I require "include", because foo is not set here.
Code: Select all
-- FILE NAMED main.lua
foo="bar" -- If there's no local, then it's global. I could put this anywere, even inside a function, and it would have the same effect
print(foo) -- This will print bar
function somecode()
print(foo) -- This will print bar when I call the function
end
somecode() -- This will print bar
require "include" -- This will print bar because the global variable carries over.
print(_G.foo) -- Bonus: If you declare a variable locally, it will be accessible in the _G table, so this will print bar
print(_G["foo"]) -- Same as the previous line
-- NEW FILE named include.lua
print(foo) -- This will print bar when I require "include", because foo is set here.
In terms of speed, you won't notice much of a difference in small applications, but in big applications they can have a huge effect - lua/löve has to carry a global variable everywhere. Use local variables whenever you can.
Re: Using local variables correctly?
Posted: Mon Dec 01, 2014 1:37 am
by AlexCalv
So what I've been doing is correct? Declaring locals at the top of my files? Also, what does that line with the table mean? Any local variables can be used in tables as long as I define which table I want the local variable to be used in?
Re: Using local variables correctly?
Posted: Mon Dec 01, 2014 1:40 am
by iggyvolz
Yes, what you're doing is completely correct.
What I meant with the _G stuff is that anything you define as a "global" will automatically be put into the _G table for you.
Re: Using local variables correctly?
Posted: Mon Dec 01, 2014 1:42 am
by AlexCalv
iggyvolz wrote:Yes, what you're doing is completely correct.
What I meant with the _G stuff is that anything you define as a "global" will automatically be put into the _G table for you.
Ohhh. Okay. Thank you for your help!
Re: [Solved] Using local variables correctly?
Posted: Mon Dec 01, 2014 2:37 am
by davisdude
Yes, this is correct, as well as good practice. Note you can also do this for nil values:
Code: Select all
local nilValueToDetermineLater -- That's it. You can do "= nil" if you like, though.