Scripting Helpers is winding down operations and is now read-only. More info→
Ad
Log in to vote
2

Why should scripters use Enumeration rather than strings?

Asked by 5 years ago

Example

For example, you are making an input using UserInputService. When you press on a key, it would fire something.

--\\ Services
local userInputService = game:GetService("UserInputService")

userInputService.InputBegan:Connect(function(key,gpe)
    if gpe then return end
    if key.KeyCode == Enum.KeyCode.E then
        -- Code here
    end
end)

My Thoughts

NOTE: I use eclipses just for you to know that there is code before/after the line(s) of code shown

Looking at line 6, the Enumeration could be written like this

...
if key.KeyCode == "e" then
...

Some scripters say that they recommend Enumeration. Why should I consume more time on typing Enum.KeyCode.E(and of course other Enumerations) than simply typing "e" or 'e' or [[e]]

Please explain!

0
`Enum` is a good practice because in conditional statements, you cannot check the property's type with a *string*.. Zafirua 1348 — 5y

1 answer

Log in to vote
7
Answered by
fredfishy 833 Moderation Voter
5 years ago

Using enumerations over strings has a few key advantages in general.

More readable.

It's obvious what context the value of an Enum is in.

For example, if you had a robot travelling around a 2D, grid based maze. You could have RobotDirection.Left, which would refer to whatever was left of the robot. You could also have AbsoluteDirection.Left, which would refer to the grid square to the left of wherever the robot is.

If we used strings, both of these would show up as "Left".

Now imagine we wrote the following code

function RobotFacingHomeSide(robotCurrentDirection) {
    return robotCurrentDirection == "Left"
}

Which of the two enums are we referring to? Compare this to the following:

function RobotFacingHomeSide(robotCurrentDirection) {
    return robotCurrentDirection == Enum.AbsoluteDirection.Left
}

It's immediately obvious from just reading this function what robotCurrentDirection actually refers to, as opposed to the string version where we'd probably need to go and look at where the function was actually called to work out what we wanted.

Stuff like this, where we can infer more about what type of data we're expecting in a certain place, generally means we make less errors as developers.

More typing is not a bad thing

This isn't really a point by itself, but is more a heading specifically to point out that the reasoning of "Why should I consume more time on typing" is terrible.

In programming, if the bottleneck on what you're creating is the speed at which you're typing, you're doing something very, very wrong. If you're typing code as fast as you can think of it, you're typing terrible code. I don't care who you are, you aren't good enough to think of code as fast as you can type.

It is always worth spending more time when you first write your code to make sure it's legible, because any time you save by missing out like 6 characters will be lost the moment you have to open it up in 1 week and have no idea what anything means.

Less memory

Generally speaking, enumerations take up less memory. The amount of memory you need scales with how many possible enumerations there are. With strings, the amount of memory you need scales with how long the strings are, and this effectively penalises you for having longer, more descriptive enum names.

Imagine we had a huge table of 100 000 directions. * Left * Right * Up * Down

If we use strings, where each character takes up 8 bits, and we have a maximum of 5 characters, we might end up using 40 * 100 000 bits, which ends up as 4 000 000 bits, or 500MB.

This is because a string representation has to be very general, and there's no way for the computer to know that we will only ever refer to these four directions.

So, we might be tempted to define them as "L", "R", "U", "D". This does cut our memory use by 80%, but now somebody reading the code has no idea what these mean.

Now what if we use Enums? We can store the directions in just 2 bits. *Enum.Direction.Left = 00 *Enum.Direction.Right = 01 *Enum.Direction.Up = 10 *Enum.Direction.Down = 11

Now, the information we're storing is 100 000 * 2 = 200 000 bits = 25 000 bytes = 25KB.

This huge saving is possible because thanks to the context of "Enum.Direction", we know that the only thing we could possibly be storing is one of four things.

Furthermore, for anybody reading this code, it's immediately obvious what Enum.Direction.Left refers to, versus "L".

However, in reality this isn't as much of a reason, because normally memory isn't a huge bottleneck, and the compressions talked about here are best case - you will never actually achieve them. It's still worth thinking about though.

In this specific scenario

In this specific scenario, I don't really see much of a point in using enums over characters. However, there are still a few benefits.

  • As a point of consistency, you should use Enums wherever you can. Don't switch between strings and enums, and don't use strings for the reasons we've just discussed, leaving you with "using enums everywhere".
  • If you accidentally typo "ee", == "ee" will never fire, but it also won't report why it's not firing. If you type Enum.KeyCode.Ee by mistake, a syntax error should help you pick up your mistake.
  • You can assign enum properties with strings in ROBLOX, but not check equivalence. This can cause some confusion among people who don't fully understand the differences between the two. However, if you just use enums everywhere, these differences go away.
1
This was an amazing answer! saSlol2436 716 — 5y
Ad

Answer this question