It’d be even better if you went deeper into other things that people can encounter:
“Code smells” and how to avoid them. You went into some detail, but why not dedicate a whole section to explaining what they are, etc
Incorporating this topic into it. This is an interesting topic (similar to the code smells) that talks about bad habits when it comes to using :FindFirstChild() and :WaitForChild().
This is true, and there’s also nested-ifs and the “ugliness” that it can cause by taking up more lines. There are times when you can’t have all of the conditions on one line, but you’ll need multiple ifs to make it function properly.
For example (taken from a post about whether it’s okay to use nested-ifs):
if BasePart and BasePart.BrickColor == BrickColor.new("White") then
end
should really be:
if BasePart then
if BasePart.BrickColor == BrickColor.new("White") then
end
end
It takes up more lines but if the part doesn’t exist, then it’ll error. Discouraging the use of more if statements might lead to things like that occuring. (although I do agree, pretty code is just as important)
And finally,
If you’ve never used a debugger learn how ffs
The hero we needed, but didn’t deserve.
How much would they differ in terms of performance or is it just related to bandwidth usage? I’ve always used the same events for similar tasks but if it’s better to use separate ones, then I’ll get into the habit of using those.
You are incorrect. and/or operators in Lua will short-circuit. a and b will never evaluate b if a is false/nil, and a or b will never evaluate b if a is truthy.
So the line:
if BasePart and BasePart.BrickColor == BrickColor.new("White") then
is completely valid and will never error, because the right hand side will not be evaluated unless BasePart is not nil.
should follow this rule. If the character didn’t exist for some reason, it shouldn’t error, correct?
What would be an example where nested-ifs would be considered better over using things like and, or are nested-ifs always the “worse” solution?
BrickColor is a property so it will always exist if BasePart exists. Character.Humanoid can error because Humanoid is a separate instance and might not have been replicated properly even if Character exists.
It’s pretty significant, plus it’s pretty easy to just write something that creates remotes for you if you don’t want to create every remote you’ll need.
Something like a shared network module where you can do
Network:FireServer("RemoteName",...)
Network:BindEvent("RemoteName",function(...) end)
And it’ll take that remote name, and use the remote or make/wait for one if it doesn’t exist
@Thezi, i not controlled, but it preferable to use dot operators (see on developer Hub), so @Polyheximal has right, it not throw a error message, as it was the same as :FindFirstChild() function. The function FindFirstChild was the same as a dot operator, only that it will took more time to load, this is why dot operator is better and not only use the other function.
If you use FindFirstChild function it still can trow a error, so you are wrong.
if typeof(BasePart) == 'Instance' and BasePart:IsA('BasePart') and BasePart.BrickColor == BrickColor.new('White') then
local Character = ...
local Humanoid = Character and Character:FindFirstChildWhichIsA('Humanoid')
if Humanoid then
Sometimes I like to follow this pattern when declaring variables. Nil values will cascade all the way down to the last variable with no error in sight.
Luau type annotations don’t actually work yet, so nobody can use them seriously. There’s no tool or built-in functionality to strip them out either, so you can’t even only use them for development. Everybody has to wait until production Roblox either supports stripping type annotations out, or full typed functionality.
Of course, playing with types in Studio won’t hurt, especially if you’re maintaining a typed version of your script for once it fully releases, or doing actual beta testing and providing feedback.
My “pedantic” checks work fine and have a minimal performance penalty.
Ok, thanks for commenting that on the side note. The main point above was that for the sake of this particular discussion, it’s fair to assume that the code will only ever set nil or a BasePart in the BasePart variable.
You typically know what range of values your code will be setting in a variable, so you know about your own code when type checking should be necessary or not. Hope that makes sense on why the comment is pedantic.
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
Now we’re conflating a lot of extra information onto the original comment.
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.
