Code formatting

Resources Community Tutorials
,
#1

Introduction

Hello! Lately I’ve been noticing that everyone has a different formatting technique. But I’ve noticed that some are hands down just better. I really wish people would use these techniques, because when your code is organized, it’s easier to write, debug, and look at. Today I will be giving a few tips on how to write organized, formatted code.

1. Variables / Identifiers

An identifier in programming is the name you give to a variable; to identify it. These can be very important because it’s what you use to tell the computer what to do. They can also be important to you, because it’s what you use to know what you’re doing. Have you ever wrote a program 5 years ago, and went back on it, and didn’t understand what you wrote? Even with comments! Here are some tips for formatting.

local player = game:GetService("Players").LocalPlayer

local p = game:GetService("Players").LocalPlayer

Which one do you think is better? The first one! We can clearly understand what it is. The player. We don’t have to scroll back up to figure out what it was last assigned to.

Take another example:

for _, v in folder:GetChildren() do
    print(v)
end

I’m sure EVERYONE does this. Even I do. And you may not realize it, but it’s actually bad practice. Because what is v? I have no idea! Are we looping through parts? Scripts? Or even the services? I don’t know! Use specific names when dealing with identifiers!

Formatting

Now this one may be subjective, but here’s one thing that isn’t. INDENTATION. Use it!
Imagine someone asking you to fix up a script, and you get this:

local part = script.Parent

local wall = game.Workspace.Wall

local canOpen = true



local function lift(otherPart)

local partParent = otherPart.Parent

local humanoid = partParent:FindFirstChildWhichIsA("Humanoid")

if humanoid and canOpen then

local player = game.Players:FindFirstChild(partParent.Name)

local gold = player.leaderstats.Gold.Value

if player and gold > 100 then

canOpen = false

player.leaderstats.Gold.Value = player.leaderstats.Gold.Value - 100

wall.Transparency = 1

wall.CanCollide = false 

wait(2)

wall.Transparency = 0

wall.CanCollide = true

canOpen = true 

end

end

end



part.Touched:Connect(lift)

What in… the world! How am I supposed to read this! I don’t know either! It’s because people don’t right their code in that way, so they won’t understand it. Code is structured into blocks, and that’s how people and computers interpret it. So you need to format it that way, also. Here’s a better way to write it.

local part = script.Parent
local wall = game.Workspace.Wall
local canOpen = true

local function lift(otherPart)
    local partParent = otherPart.Parent
    local humanoid = partParent:FindFirstChildWhichIsA("Humanoid")

    if humanoid and canOpen then
        local player = game.Players:FindFirstChild(partParent.Name)
        local gold = player.leaderstats.Gold.Value

        if player and gold > 100 then
            canOpen = false

            player.leaderstats.Gold.Value = player.leaderstats.Gold.Value - 100
            wall.Transparency = 1
            wall.CanCollide = false

            wait(2)

            wall.Transparency = 0
            wall.CanCollide = true

            canOpen = true 
        end
    end
end

part.Touched:Connect(lift)

The rest is just preference. Try not to use too many spaces, or too little spaces. Period.

Use comments!

Even if you don’t have good formatted code, or can’t seem to figure out how to get it that way, explain it! Explain your code detailed and well, so that we can all understand what it’s doing. That’s the whole point, anyways.

14 Likes
#2

OOOH you know what you should also add to this tutorial, add something talking about choosing between coding cases, Like PascalCase or snake_case or camelCase. I personally like using PascalCase since its faster to type for me and I am used to it due to the YT tutorials I watched when I didn’t even know what a variable was.

1 Like
#3

Yes, but I think you have them switched around. This is camelCase, this is PascalCase. No worries! :slight_smile:

Snake Case VS Camel Case VS Pascal Case VS Kebab Case – What's the Difference Between Casings?).

1 Like
#4

You could argue to the contrary. If you name functions and variables correctly, there’s no need for extra documentation. Code should be understandable by itself, self-documented. Don't Write Comments - YouTube

2 Likes
#5

(post marked for deletion for privacy reasons)

#6

You forgor to add an extra 5 new lines for no good reason!

You can’t just do game.Players.LocalPlayer? I guess everybody has a different style.

But seriously, this will hopefully help new scripters understand the conventions. Thanks!

1 Like
#7

Both, both is good.

An identifier / function name should explain what something is, a comment should be used to explain why something is done.

Generally speaking, not using comments at all can reduce the overall cohesion of your program, and therefore make it less understandable, navigable, and debuggable.

1 Like
#8

The whole point of me putting that section there was to illustrate that if you for some reason couldn’t format your code correctly, simply use comments. Even if you do format your code correctly, you still need to use comments, because that documents the use of it.

#9

Yes, but in my previous post someone told me that it’s “good practice” to do :GetService() instead, so now I’m starting to realize that people are always going to have a problem with your code however you write it.

Here’s the post:

#10

It is good practice. I always use :GetService() to avoid issues if ever something is renamed. For instance, I could at any point rename Workspace to something else. Roblox does not prohibit the renaming of services within games. :GetService() will always be consistent.

1 Like
#11

If you clearly convey the meaning of the identifier, then there’s no need for comments. An exaggerated example:

function CreateExplodingPart()

function CreatePart() // Creates a new part that explodes
#12

I don’t think you’re getting the point what he said. It’s always good practice in any form of skill to make sure. Anytime, making sure is always a good thing to do. So there’s nothing wrong with adding comments. What if the reader doesn’t know how to code? And they don’t know what a function is?

1 Like
#13

99% of the time someone that doesn’t know how to code wouldn’t be looking through code.

#14

This is very untrue, and I’m just going to let someone else explain that for you.

#15

It won’t be renamed. I don’t know why people hold on to that myth.
I only use :GetService() on services whose name is not their ClassName, such as game["Run Service"].

1 Like
#16

The same principal goes for this argument. If you can make sure, then make sure. There’s nothing wrong with it.

#17

image
As I was saying.

1 Like
#18

If you’re worried about a virus renaming services, then you can immediately notice because the game won’t work anymore. If an exploiter renames services locally, then their game won’t work.
So what’s the point of worrying??

#19

Did you read this? This is very important, by the way.

#20

Future proofing your code?

Which can be countered by simply using GetService

1 Like