Is it better to have a module script that holds variables or create them in every script you need them in?

Kinda went off in the title but I feel like doing it the module script method is more efficient and it also saves time and when you need to change a variable you just need to change it in one place, this is what im talking about basically

So in essence in every script I need to one of these variables I just require this module below and I have access to all the ones I need rather than having too re-write them over and over ex. player

3 Likes

It depends on what each variable or function is used for. With the example you gave, which is creating variables for Roblox services, it’s recommended to do this per-script, and at the beginning. This keeps it obvious as to what services a given script uses.

Most other individual (or duplicated) variables and functions that see use across multiple scripts should be stored using a ModuleScript, which promotes the reusability of code.

Also, when naming variables and functions, the best practice is to give them complete and descriptive names (unlike the initialisms in your example), but don’t make them too long. This helps with code maintainability, as both you and others should be able to more easily read and understand it, both now and into the future.


On a side note, ModuleScript values ARE NOT REPLICATED across the network (server ↔ client). If you require a module on the server, modify one of its properties, and then check it on the client, you’ll see that it only changed on the server (and vice versa).

--! ModuleScript
return { value = 5 }

The server could require it in a script, then change .value to 10. Now, if any client were to also require it (e.g. the module is in ReplicatedStorage), they would still see 5.

--! ServerScript
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local ModuleScript = require(ReplicatedStorage.ModuleScript)

ModuleScript.value = 10
print(ModuleScript.value) --! prints '10'
--! LocalScript
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local ModuleScript = require(ReplicatedStorage.ModuleScript)

print(ModuleScript.value) --! prints '5'
2 Likes

It’s not better or worse. Well, it’s a bit worse because you might accidentally write a script to modify it which you don’t want.

But in terms of productivity not having to rewrite variables EVERY SINGLE TIME you need them in a different scripts does save time does it not?

@Sepruko Dont worry Id never pass a math.random function in a module

Quoted from my edit above.

I did not say that you do, I was just giving further education in the event that it helps you or anyone else who comes across this thread. Its purpose was to explain that, despite a ModuleScript’s typical behavior (maintaining global state per-session, e.g. changes made are reflected everywhere), this does not remain true across the network.

dont worry I seperate server modules from client modules

Also could you explain why it’s best practice to do this?

Pretty curious as to why that is

For example, if a given script needs UserInputService for processing gyroscopic motion or otherwise, it’s immediately obvious that it is using that service.

--! ModuleScript
local UserInputService = game:GetService("UserInputService")

--! Imagine this does something with gyroscopic
--! controls via UserInputService.

return {}

In the above script, that service requirement is both immediate and apparent, as it’s declared as close to the top of the script as possible. This also means you should avoid declaring services in lower scopes (e.g. inside ifs, fors, or functions).

Yeah but I meant something other than that…

Then what did you mean? I’m confused.

When you are programming and creating new scripts do you initalize the same variables that you’ve intialized before in other scripts?

As I said here…

It depends on the purpose of a specific variable or function, and how many times and places it is used. With all that I’ve said in this thread…

If it’s used in multiple scripts (and isn’t a Roblox service), it’s probably best kept in a ModuleScript to avoid repetition and keep maintenance burden low.

2 Likes

That’s exactly what I wanted to hear thank you.

1 Like