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)
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!
Using enumerations over strings has a few key advantages in general.
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.
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.
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, I don't really see much of a point in using enums over characters. However, there are still a few benefits.
== "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.