Connecting Events I What is better?

Hello. I’ve seen a lot of users have their preferences to connect events creating them separately or straight into the connect function.

I’ve been wondered what is better for game optimization/practice. If we look at these two methods of doing we can see there is one that has more lines than the other one, which means the method with fewer lines of code should be better right? or not?

You can see code difference here:

Straight Into Connect Function

game.Workspace.Part.Touched:Connect(function()
       -- code
end)

Separately Creating Function for Connect

function onTouched()
      -- code
end

game.Workspace.Part.Touched:Connect(onTouched)

What makes these methods better/worse? Is there any technical difference or it is just for practice?

Thanks for anyone responding!

1 Like

seperately creating function will make it so the script can use it as well.

If you want cleaner code and to reuse the same function then use 2.

if you just want it quick and you don’t need to reuse it use the first one.

3 Likes

Agreed. I want to add that if the function is only used once as a callback to Connect, I think it’s cleaner to have it as an anonymous function than a named function.

1 Like

I don’t think that method 2 could make your code cleaner, But using method 2 to resuse the functions make sense, I can give an example

Let’s say you have function that will change transparency of model and you want to make some event do the same in the same script, and still have the function usable for another needs then this is good method of doing it, But if we need to just do something we don’t need to do later in same script the method 1 is better.

1 Like

Neither one is better. Just pick whichever one you like more.

Using method 2 makes code looks terrible and it make it like someone scripted it in 2015, but yeah its good for reuse

1 Like

Like you said method 1 is good for “cleaner” code and method 2 is good for reuse

Well first of all, imo globals are disguisting, so I would immediately make that a local instead.

Now I was kind of just talking about this to my friend, not in the event sense, but in overall using one-time functions and just hoping they get garbage collected quickly enough for it not to be a problem.

In this case, for example this code of mine:

In this case, I’m constructing a function in runtime, everytime, (when I didn’t need to), which first of all in a lot of cases can look weird, and also is bad for memory use.

You should cache your function if you’re gonna be connecting or disconnecting it multiple times.

Now,

Recently I updated that script and so now it’s a local function which is the only one used for every thing.

Constructing a new function each time for everything is slower and usually unnecessary, so to anyone reading, next time you write something, check if you can’t cache these into just one function which is shared for multiple things.


If you wanna be specific to your script, then whatever. (Except for the fact that you’re using a global)

However if you’re working for example with parts that damage / kill a player then the better thing to do here is to use CollectionService and handle everything in only one script.

While that’s better, the things I talked about above with function caching still apply. If you’re doing the exact same function everytime, check again to see if you REALLY need to construct a function everytime.


That’s just because it follows the older code style from the past.

For instance, not using locals (sin, you’re not going to heaven if you use globals :rage::rage::rage:)

And also stuff like not localizing game.Workspace.Part to Part (performance loss too), not using :GetService, having main functions being named with camelCase and not PascalCase, etc.

Most modern code looks just fine with the style 2 as long as they follow the newer standards.

local Players = game:GetService("Players")

local function OnPlayerAdded(player)
    --\\ :)
end

Players.PlayerAdded:Connect(OnPlayerAdded)

for _, player in ipairs(Players:GetPlayers()) do
    task.defer(OnPlayerAdded, player)
end
1 Like

well i personally don’t use local functions if its a script function,

--if i wanted recursion i couldnt have it if i set it local
local function recursionlol()
	recursionlol()
end

if i just remove the local from the above example then it will work
also with events

--in a function you would need to define the variable first
local Event
--then connect your event
Event = event:Connect(function()
	--now we can disconnect it!
	Event:Disconnect()
end)

if you use globals in a function then i agree thats actually terrible especially when you have a yield in it :face_vomiting: