My best practices for roblox dev (mostly on the technical side)

Resources Community Resources
#21

While you may know the types of your parameters, unfortunately I do think these kind of type checks are currently necessary for server sided sanity checks, if you don’t want exploiters sending in weird data into your remotes and messing up your game :c

I do agree it was a bit much in this context, but just food for thought

1 Like
#22

Verify external data, but within your internal functions, only do checks that you need to.

You don’t need to verify the Instance you just created with Instance.new is not nil, or actually of the type you specified, do you?

#23

Now we’re conflating a lot of extra information onto the original comment. :smile:

With the post way above I meant a simple situation without networking where you have a variable called BasePart, which I assume can only be nil or a BasePart, in that case you don’t need any sort of typechecking apart from checking whether it is one of those two, and you don’t need nested if-statements due to short-circuiting.

4 Likes
#24

I mean that just depends on the usage of the Character and Humanoid variables, which happens to be unknown for the both of us. If the goal of the code is to determine if the humanoid exists then my code would be the best way, however if you were to use the ‘Humanoid’ variable repeatedly in the following code I would actually yield until the humanoid existed because there is no usage of a variable that posses a nil value.

If it was assumed that the Character and Humanoid variables would be used in following code then I would actually use this rather than yours.

local function waitForChildOfClass(object, childClass)
   while not (parent:FindFirstChildOfClass(childClass)) do
      RunService.RenderStepped:Wait() -- assuming this is a local script
   end

   return (parent:FindFirstChildOfClass(childClass))
end

local Character = ...
local Humanoid = waitForChildOfClass(Character, "Humanoid")

 -- code
2 Likes
#25

Thanks for writing those notes, they were useful, even the ifs: wow, I didn’t noticed that using too much “ifs” can hurt performance! Thanks for telling me that! No more ifs.

#26

I would be somewhat skeptical of the claims that one developer makes in their blog article - if statements have very little overhead, most of the overhead depends on your condition (if ... then). You can still use ifs, and you should when needed!

I believe the “if statements have tons of overhead” thing dates allll the way back to assembly on slow CPUs (< 8 MHz), where every instruction affected a substantial percent of your application’s performance.

These days, with CPUs running in the billions of instructions per second, even in a language like Lua, if statements are really not something to worry about all that often.

You should be more worried about FindPartOnRay, FindPartsInRegion3, etc… because those are the real performance hitters. I know because I’ve done them in RenderStepped before and, well, it is pretty… pretty slow that is.

3 Likes
#27

Thank you so much for putting this information together! When you first posted this topic, I was a New Member and couldn’t thank you. Now I can, so thank you! :slight_smile:

Interestingly, your open source project Dungeon Life is very similar to one of the main gameplay mechanics I’m planning for my first Roblox game. I intend to look over your project very carefully, and may have several questions for you!

#28

This doesn’t result in an error. Just tested it. Lol does not exist in this example.

Unless I’m misunderstanding what you’re saying?

1 Like