How To Keep Code Clean Part: 1


Notes:

Note:

So, there actually a few other topics that talk about this, but they are from more than 1 year ago/didn’t cover what I’m gonna say



Another Note:

This is gonna be split up in more parts, as I will explain each way with high detail



Am I Making Too Much Notes?

I will be making the code and start messy, and gradually using the tips I will give to make the code better



Introduction



In this series I will be explaining how to keep code clean, in this part I will be explaining:

Drum roll…

Number of Lines, Variables, Blank Lines, Names and Comments

I hope you like this series, if it will be appreciated I will be making a Part 2, have a good day/afternoon/evening!


Number of Lines



So, there’s people that are always trying to have less lines as possible, but let’s say it, it makes you look newbie and makes your code ugly, an example of a bad code would be:

while true do print(“hi”) task.wait(1) end

As you can see, this code is completely functional, you can put it in the Command Bar and it will work out 100%, but it looks ugly and makes you look newbie.



So, how can we make this code better?



The simplest way is to not make it one line, but 4, like this:

while true do
   print(“Hi”)
   task.wait(1)
end

“Why are you even saying this, it’s so obvious” you may be asking, I’m saying this because there’s people that are making codes with one line, thinking it’s actually more performant, but it actually isn’t, so making this just makes you look newbie and makes your code unreadable



Variables



Variables are probably the thing you are gonna use the most, they are simply things that are renamed, but they are very very useful, and you should use them, or else this could happen:

while true do
   script.Parent.Parent.Parent.Hi.How.Are.You.Value = 1
   task.wait(1)
   script.Parent.Parent.Parent.Hi.How.Are.You.Value = 0
end

Not using Variables only makes YOU (and whoever reads your code) not understand, as you will have to read the whole path, and makes you have to spend more time writing, so overall, using Variables is better



So, how can we make this code better?



To make this code better, you can use Variables, if you don’t know how to define a Variable, simply write:

local name = whatever

local, makes the Variable cost in that scope, like a Function, if it’s outside of a Function it will work in any Function, if it’s in the script, name is the name of the Variable, which you can write to call the Variable, and whatever is simply the Variable, it can be an object, a number, a table and a lot more.



But how do we implement it into our code?



To implement it simply do this:

local you = script.Parent.Parent.Parent.Hi.How.Are.You

while true do
   you.Value = 1
   task.wait(1)
   you.Value = 0
end

As you can see, the code is more readable, takes up less space, and you had to write that whole thing only once! Variables are so cool, right?

Variables can do a lot more, another way of using Variables is:

local variable

Yes, simply say the name of the Variable, this can be very useful if you don’t have what the Variable will be for right now, but you have it later, yes, you can set it later by doing:

local variable = whatever

But if you will have to change what it is a lot of times in different Functions, it’s better to do this.

What this does is this:

local variable = nil

Meaning, that this way, the Variable will have a value of nil, meaning it doesn’t have a value, you could also say that the Variable doesn’t exist, even though it does, it simply doesn’t have a value.



This is only a part of what Variables can do, I will talk more about Variables this in Part 2 (if there will ever be one)



Blank Lines



Blank lines are another factor of making your code look good, but, it can be used in the wrong ways, 2 examples of these are:

local message = “Hi”
local function onEvent()
   print(message)
end
workspace.Part.Touched:Connect()

(No blank lines)



local message = “Hi”


local function onEvent()


   print(message)


end


workspace.Part.Touched:Connect(onEvent)


(Waaay too much blank lines)

How I usually put blank lines is on these situations:

  • There’s a change between part of script (Variables → Functions, Functions → Events etc.)
  • There’s a change of context (making Variables for Parts and making Variables for Values)

So, I’m the script you would do:

local message = “Hi”

local function onEvent()
   print(message)
end

workspace.Part.Touched:Connect(onEvent)

Isn’t it more readable? Now we can go into the next step, COMMENTS!



Names



Names are one of the things you are gonna us the most, the most important thing when writing Names is:
Be as descriptive as possible, I can’t understand what something is if it’s called A, but if it’s called PartA, it’s more understandable, there’s a few rules with Names:

  • Never use .,,,:,;,/,-, etc. in Names, as they are part of @Roblox’s scripts sintax they can’t be used
  • Numbers can’t be the first digit of a Name, for some strange reason (1Part not valid, Part1 valid)
  • Don’t use spaces in Names, it will simply error

Usually when you are writing Names use one of this types of writing:

  • camelCase
  • PascalCase
  • snake_case
  • LOUD_SNAKE_CASE

Never use things like:
thisisbadpractice
As you can ses, it’s totally unreadable



Comments



Comments are probably the easiest thing here, they are comments that you put in a script, they can be used for a bunch of things, like:

  • Giving credit to someone
  • Remembering things
  • Explain code
  • Etc…

You can write a comment by writing – and then writing the comment, like:

--This is a comment, as you can see it’s greyed out, this is because it’s not an actual part of the script

I think we’re done with comments. [“What do you think boss? Is this enough for comments? Okay, oh no, I forgot the mic on”]



Conclusion



This tutorial took me a lot of time to make, and it’s also my first, so if you have any tips on what I can improve don’t be afraid to reply and saying what you think! (Please use constructive feedback only)


Nothing

Wow! I didn’t think this would get so appreciated! We got 19 likes!

35 Likes

Just a suggestion but sort our your indenting. The code you have provided has terrible indenting which makes it hard to read sometimes.

5 Likes

Sorry, but what do you mean? I’m not an expert sorry

For example:

while true do
	print("hi")
	task.wait(1)
end

Oh yea also P.S. you should be using task.wait() for waiting in code now not wait().

5 Likes

Oh, you meant taht the code is like:

while true do
print(”Hi”)
wait(1)
end

Instead of:

while true do
   print(“Hi”)
   wait(1)
end

?

Also, why do I have to use task.wait() instead of wait? I still don’t understand, I’ll fix that ASAP
(Also for the script thing, I’m currently writing on phone so it’s hard to do that)

Edit: I edited as you said, thanks very much!

1 Like

In general task.wait() is just an improved version and is better to use. In the future Roblox has said they will make wait() legacy also.

More info: Task Library - Now Available!

So over all wait() still works fine but it is highly recommended to use task.wait().

1 Like

Okay, thanks for the feedback! It’s true that you learn something new everyday…

1 Like

This isnt really true, all local does is make a Variable usable within the scope its declared in, it doesn’t make anything “exist”, I can make a Global Variable (Variable without local) and It will work just fine, except i can use it in all scopes:

GlobalVar      = "text"
local LocalVar = "text"

And the “Other Global Variable” which is _G, but thats more of a Global Table:

_G.Global = "text"

Other Script:

print(_G.Global) --> text
4 Likes

DOesn’t roblox already format the code like this except for the blank lines of code in between? And if it’s not formatted you can just copy and paste the code and tada it’s formatted again.

1 Like

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. :sweat_smile:

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 :sweat_smile:

uuhhh you are trying to make it more readable and more nicer, but it still didn’t help me :confused:

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 (1Part not valid, Part1 valid)

would 1e3 be a name or a number then?

PartA

this is still a bad name

3 Likes

https://roblox.github.io/lua-style-guide/

good guide

1 Like

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.