Really? I’m pretty sure a global scope is only ‘global’ through that script only.
Render()--<Error
Renderv1()--<Will work
local function Render()
print("Rendering");
end;
--
function Renderv1()
print("Rendering");
end;
For global variables/functions across scripts, you’ll need to use _G
Yeah, it’s only ‘global’ insofar as it’s accessible from that specific script, which is why I find it kind of pointless to argue about imo. Functionally they’re nearly identical, and while there may be some performance advantages in using local functions, I would guess that for 90% of use cases it won’t be big enough to make a difference. For most use cases, at least with Roblox, it’s gonna come down to a preference and how you’re organizing your code.
Probably meant any block in the script, unless you mean defining functions globally as in literally globally in a shared environment.
Defining a function through syntactic sugar:
local function foo() end
-- is the same as doing
local foo; foo = function() end
and defining functions locally makes them faster to access since the local is added to the stack.
That is another issue your touching on, if your code spans thousands of lines, your more than likely doing too many things in that single script/module. imo no source file should be more than 1000- 1500 lines long.
Why? What’s the difference between 1,500 and 15,000 lines? From 500 lines long, in my opinion, it is already difficult to move through the code without using bookmarks, collapsing, Ctr+F, and other tools (that’s why I use Sublime Text 3 and not Studio’s native editor).
So, no matter if you have 1,500 or 15,000 lines, the job will be the same.
Yeah of-course it will do the same thing but it will make your code terrible to maintain.
Why? A single script’s strategy is highly recommended by many developers. In this case, I’ll have only 3 scripts: a LocalScript, a ServerScript and a ModuleScript.
I think it is much easier to maintain the code in this way than to distribute it unnecessarily in several scripts, which, on the contrary, makes maintenance more difficult.
Is there any advantage to declaring a function as
local?
Yes. They are faster to access, and you avoid polluting the global* namespace. Here is some info about the global environment from PIL.
For simple programs, honestly, it probably doesn’t matter what you do. As your programs get more complex, though, you will start to realize the benefits of well-defined scope.
Because so far I’ve only seen disadvantages : without
local, the function can be located anywhere in the code and when declaredlocal, the function must always be above the line that calls it.
This is false. The following fails:
printHello() -- attempt to call global 'printHello' (a nil value)
function printHello()
print("Hello")
end
You may be referring to something like this:
workspace.Part.Touched:Connect(function()
printHello()
end)
function printHello()
print("Hello")
end
This works because when you declare something without local, you are actually putting it in a table that is shared for the entire script*. The printHello() call triggers a lookup in that global* table.
However, that’s not a unique thing to globals, it’s more of a side-effect of the way lua is evaluated (at runtime). This works too, but makes printHello a local function:
local printHello
workspace.Part.Touched:Connect(function()
printHello()
end)
function printHello() -- same as printHello = function()
print("Hello")
end
You still need the forward declaration at the top, since you’re not storing the variable in the global* table, but you can put the definition wherever you want.
*: in non-roblox Lua, every non-local variable is put in _G and shared among all modules in the program – not true for ROBLOX. In ROBLOX Lua, each script has its own “global” table that other scripts cannot access.
Just to confirm that functions declared as Local are REALLY faster than global functions, I created a benchmark below:
local elements = 100000000
local keyToFind = "k" .. elements
function GlobalFunction()
return true
end
local function LocalFunction()
return true
end
-- benchmark
local time = tick()
for i = 1, elements do
GlobalFunction()
end
local timeG = tick() - time
print("seconds to run a Global function:\t", timeG)
local time = tick()
for i = 1, elements do
LocalFunction()
end
local timeL = tick() - time
print("seconds to run a Local function:\t", timeL)
print()
print("Local functions were" .. math.round((timeG / timeL - 1) * 100) .. "% faster than Global functions")
Result:
seconds to run a Global function: 3.0561254024505615
seconds to run a Local function: 2.423032283782959
Local functions were 26% faster than Global functions
Running 10 million iterations, it can be seen that calls to local functions are almost 30% faster than calls to global functions.
Thanks for the benchmark testing. For anybody scrolling upon this from 2024, I tried the same benchmark and results have significantly improved.
Blockquote
seconds to run a Global function: 1.7780334949493408
seconds to run a Local function: 1.645150899887085
Local functions were 8% faster than Global functions
So depending on the script, in general it shouldn’t really matter which one you use, which means you can have the ease of access of using global functions and being able to declare them anywhere.
Unless you still want that 8% boost 