It’s worth noting that using _G is not a good practice and ModuleScripts should be used instead. I’m leaving this link which explains why Global States are a bad practice.
8 Likes
Yes, already know, that why im like: oh yeah that “other one”
1 Like
I editted my previous comment not to be directed to you and instead to be advice for every reader, didn’t mean to write it that way. 
Sorry for any confussion!
It’s probably also worth pointing out that instance values behave exactly like _G (actually it’s a bit worse since replication is a factor).
the rest is just proof of concept for anyone curious as to what I mean
For example, consider the following code:
local instanceValue = game.Workspace.NumberValue
In this example game.Workspace.NumberValue has a global state because any other script accessing it will share the same value since it is a reference (regardless if it changes). If the programmer treats _G as though it is an instance value in the Workspace, then it becomes quite clear what should and shouldn’t be done:
- Only have one place where the reference is altered
- If more than one place is needed, then you must guarantee the scripts won’t conflict
A very basic example of this is changing a NumberValue in two different scripts:
Script 1
local instanceValue = game.Workspace.NumberValue
instanceValue.Value = -1
Script 2
local instanceValue = game.Workspace.NumberValue
instanceValue.Value = 10001
If this is the entirety of the code, what value will the NumberValue be at runtime? It’ll be the value of whichever runs last!
TL;DR
_G behaves a lot like an instance value in the Workspace. Using either _G or instance values are convenient, but careful not to fall victim to multiple scripts changing the same value.
[EDIT]
I’m definitely not saying to never use instance values or _G…just be mindful.
[EDIT2]
Toned down the wording. Also realized how I periodically use attributes.
3 Likes
From what I know @Roblox already does format the code
The thing is that I’m writing this on phone so I have to add 3 spaces to make the indenting somewhat actual
uuhhh you are trying to make it more readable and more nicer, but it still didn’t help me 
read this topic below to try to help me
2 Likes
If you don’t want to add notes, just make your variables explain what the script is doing lol.
2 Likes
local you = script.Parent.Parent.Parent.Hi.How.Are.You
consider parenting the script properly
workspace.Part.Touched:Connect()
invalid code
Snake_Case
in snake_case, the first letter of each word is written in lowercase
sintax
ses
typos
for some strange reason (
1Partnot valid,Part1valid)
would 1e3 be a name or a number then?
PartA
this is still a bad name
3 Likes
Global Tables only replicate to server context they were created on
for example_G.Global created on server will only be visible for client and vice versa.
I would recommend to add into a tutorial multi line commenter, that’s about it.
What is a multi-line commenter?
Comments spannning multiple lines?
Variables shouldn’ t be used to just make code cleaner but they should be used to optimize code too, variables are really useful when it comes to optimizing code and making it better and faster and in some cases even more functional with checks.
1 Like
--[[
Hey look at me I' m an amazing long comment
I can do this!
And this!
]]
--Hey look at me.
--I' m ugly.
--Never use me please.
--End me please I can' t bare this suffering.
1 Like
Thanks! I’ll update the post when I can
1 Like
I just noticed this in your reply and I didn’t notice it before… I’m blind.
Anyway, it’s a number, so it’s not a Variable name because it has a number before it
the issue is that it’s in light mode, I prefer dark mode over light mode
1 Like
I disagree. wait does throttling while task.wait does not. Although less accurate, switching back to wait has had a significant performance improvement for me.
Both are useful and it depends on design.
It’s still recommended and in fact I don’t really see massively how it would affect a large amount of performance. Basically everyone is using it now and I have seen no one else complain about there being performance issues.
Wait() should really never be used now because Roblox has made it Deprecated and even though I don’t really think there should be any issues with wait() even though it is deprecated its best practice to use the new version.
Source? I’ve never seen the documentation recommend it. If so, that is an error in the docs.
In one of my poorly designed games with a script per NPC, making the update timer rely on wait instead of task.wait has massively improved performance if there’s more than, say 300 of the NPCs roaming around. That is because wait throttles.
It has also visibly reduced the amount of server stuttering my game has had. Not only that, but it is also shorter to type!
It is all a balance. If you want an accurate wait time, use task.wait. If you want throttling for a smoother experience, use wait. Although the difference is miniscule at first, when the server is under heavy load, wait is much more performant than task.wait.
This is knowledge that very few people know of at the moment, and I am sharing my findings with you. I am aware that this is not your experience but I’m sharing mine. I’d recommend using wait for inaccurate fast wait times and task.wait for lengthy wait times (like intermission).
This might also be the case with spawn but I haven’t tried it.
Wait() is identical to wait(). Spawn() is identical to spawn(). Just like how Workspace is identical to workspace.
They are not as consistent and are a hassle to type them as a PascalCase, which is why I’d assume they were changed to snake_case/camelCase, and the old versions were deprecated.
1 Like