Why should I use Enum rather than "ENUM"?

Help and Feedback Scripting Support
#1

So, for the last 4-5ish years of me scripting, people have always told me to use Enum rather than just a string with the Enum name. Though I just went along, I’ve wondered how Enum is better than simply using a string. As A it’s shorter B I dont have to remember the Enum names which is really annoying to me because I have to switch from vs code to the api or just insert the instance into studio and see the property name. Of which degrades my productivity.

1 Like
#2

Enum is better mainly because it helps you find certain Core functions used in some code that a normal string cannot,

Using a string is worse mainly due to it being more Problematic and usually is the Culprit for some Errors.

2 Likes
#3

Ah so I see, string can sometimes cause errors? Could I see the source of these errors and the error itself? Seems interesting.

#4

What do you mean enum string I’m a little lost?

#5

He means something like this:

Normal Enum:

Part.Shape = Enum.PartType.Ball

String Enum:

Part.Shape = "Ball"
#6

Ah alright

for OP:

Mainly using an enum the “proper” way ensures its correct and it has a direct index to the enum, I assume backend LuaU it’s also faster to use a direct enum instead of string though I could be wrong

2 Likes
#7

I agree with @DasKairo.

Another thing is readability. Suppose you are listening for user input and you have code that looks like:

UserInputService.InputBegan:Connect(function(inputObject)
local key = inputObject.KeyCode
if (key == "W") then
...

Since the comparison of strings and enums is handled implicitly someone reviewing this code in the future might assume that key is meant to hold a string value and not, in fact, a KeyCode enum.

Also, how would one handle inputs from the shift or return keys, the function keys, etc? In this scenario it is much easier to just use the enum values than try to figure out how to represent those with strings.

EDIT:
Did a quick test in studio and found that the keycode example I used in fact does not work. However @DasKairo’s example using the part’s Shape property is a habit I used to have when I started out and still fits with my argument. By using a string the Shape property might be mistaken for a string type and there is also the possibility for errors should the programmer misspell the string. At least in the current version of studio you can take advantage of the auto-complete to avoid that when you use actual enum values.

3 Likes
#8

@TheH0meLands
Best Example i could find is with TweenService in Enum.EasingStyle and Enum.EasingDirection:

Put this Script inside a Part:

game.TweenService:Create(script.Parent, TweenInfo.new(1,"Sine", "InOut"),  {Position = Vector3.new(0,0,0)}):Play()

Uh oh, an Error: TweenInfo.new second argument expects Enum.EasingStyle input

Change it you might say?

game.TweenService:Create(script.Parent, TweenInfo.new(1,Enum.EasingStyle.Sine, "InOut"),  {Position = Vector3.new(0,0,0)}):Play()

Nope: TweenInfo.new third argument expects Enum.EasingDirection input

Now Try this:

game.TweenService:Create(script.Parent, TweenInfo.new(1,Enum.EasingStyle.Sine, Enum.EasingDirection.InOut),  {Position = Vector3.new(0,0,0)}):Play()

It Works! Yay!

Enum is Better in this case than a typical string as it can help find certain core functions as stated in my post:

2 Likes
#9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.