Is it a good idea to have 1 big script or several small scripts

Help and Feedback Code Review
#1

I recently made a medium-small script that handles all of my UI-related code. I was wondering what was better for optimization. A big script OR several small scripts.

Here is the code (its not finalized. Just basic functions).

local Button = script.Parent
local Play = script.Parent.Parent.PlayButton
local TeleportService = game:GetService("TeleportService")
local BackButton = script.Parent.Parent.Parent.TextFrame.BackButton
local TextFrame = script.Parent.Parent.Parent.TextFrame
local sound = game.Workspace.Sound.MenuSound

TextFrame.Visible = false
TextFrame.Credits.Visible = false
TextFrame.Line1.Visible = false
TextFrame.Line2.Visible = false
TextFrame.BackButton.Visible = false

sound:Play()
if sound.IsPlaying == false  then
	sound.TimePosition = 50
	sound.Play()
end

Button.MouseButton1Click:Connect(function()
	TextFrame.Visible = true
	wait(0.5)
	TextFrame.Credits.Visible = true
	wait(0.5)
	TextFrame.Line1.Visible = true
	TextFrame.Line2.Visible = true
	wait(1)
	TextFrame.BackButton.Visible = true
end)

BackButton.MouseButton1Click:Connect(function()
	TextFrame.Visible = false
	TextFrame.Credits.Visible = false
	TextFrame.Line1.Visible = false
	TextFrame.Line2.Visible = false
	TextFrame.BackButton.Visible = false
end)

Play.MouseButton1Click:Connect(function()
	TeleportService:Teleport(6531645220)
end)

Is there anything I need to optimize or change?

#2

I personally use only one LocalScript for all of my UI code. However, if I’m handling MarketPlaceService stuff, I would use a separate script to do that.

I think what you are doing in that code is fine, it’s nothing to worry about at all.

1 Like
#3

If you want to be organized, don’t have too many scripts, but a central script for handling one type of thing (like a local script for UI) would be better than having a local script for each button (it’s a bad practice tbh)

3 Likes
#4

No, its all up too you either is fine.

1 Like
#5

So what you’re saying is 1 script for UI , another script for server-end stuff, and another script for feature management.

#6

I feel like I use too many scripts and I have to redefine the same variables. I think as long as you handle errors properly, then one script is the better option.

#7

I personally feel like the less scripts you have, the easier it is to optimize and manage your code. However, at the end of the day, what works best for you or your team (if applicable), is the best choice.

#8

I also think it’s good to avoid having too many scripts that perform a similar task. However, I think it’s also pretty important not to stuff separate, not-so-related functions into one script especially as the scale of your game increases. As for the tasks that many separate scripts in the game have to accomplish, use module scripts!

Looking at your code example specifically, I think you’re doing great! There doesn’t seem to be a need to use a separate script for now. However, if you want make the code a little more compact, I would suggest using this function for changing the visibility of multiple objects:

local function SetVisibility(Objects, VisibilityToSet)
	for _, Object in pairs(Objects) do
		Object.Visible = VisibilityToSet
	end
end

SetVisibility({TextFrame, TextFrame.Credits, TextFrame.Line1, TextFrame.Line2, TextFrame.BackButton}, false)
#9

Thanks! That looks much more compact. Ill implement it as soon as i finish revamping the UI

1 Like
#10

Ok so I’m just gonna point out after everyone here is suggesting to make very long scripts… That is a very bad practice!

It’s important to organise your scripts neatly, create neatly stored modules, a clear naming scheme, etc.

Scripts with similar behaviour should probably be using the same script and/or module, not many copies. In general, don’t copy longer pieces of code between scripts.

The industry standard everywhere in programming is to make short, understandable and reusable scripts. The functions inside should be short and aiming to perform only one task each.

This helps to keep your code modular, and in the end helps you find what to change where more easily: as your projects complexity increases, a bug in a spaghetti script with thousands and thousands of lines will be very hard to find.

While only few programmers take these standards all the way to the max - it’s simply so practical to do several things in a function - you should at least take the advice a little bit. =P Any scripts over 1000 lines should be a clear red flag, grouping way too many things to do, that should be in their own module.

Incidentally, this script is not too long, in my opinion. The functionalities also seem related, so there is no problem there. If there were many more buttons, you should probably start separating them by category to their own scripts.

In terms of performance/optimization of your code, it won’t make any difference wether your scripts are long or short. But what does matter is the time it takes us to find something going wrong, and properly naming our functions and scripts in the end makes that much easier in bigger projects.

17 Likes
#11

By making more scripts and by using modules, the game will look cleaner and it will be easier to manage. I usually create custom services with modules, and create roact components with them too.

#12

I was looking for this reply, thank you.

What I personally prefer to do is use as few scripts as possible.
For example: one for UI, one on the server, and one in ReplicatedFirst.
Each of these scripts requires a few modules, which require their own modules that they need etc.
Especially if you implement the 4 pillars of OOP, and keep 1 class per module script, your code will become easier to read and maintain.

This is quite a decent article if you wanna learn more about OOP

But it is up to you if you want your game to be maintainable, it does make it way easier to make changes and add features.

4 Likes