In my opinion, at the end of the day it’s all preference and the only important thing is that you’re consistent with your convention.
The only real benefit I can think of (and it’s minor at that) is that if you use some type of code review system, using separate lines makes it easier to read diffs since it’s immediately known what changes you’re making.
doing one thing in the same line, you get the point.
if not bool.Value == true then bool.Value = true end
Generally because it’s faster, although putting it in a longer manner
if requestResult == true then
print(requestResult)
end
turns out easier to read and more organized, although It’d take more space in your program. There’s no right or wrongs here, both are good to use based on the context you’re applying them to. I’d just avoid putting something that’s over 5 lines long in one line.
In my opinion though, this sort of creates the same problem the command bar line has. It’s alot harder to read and use if it’s that long in one line. That’s why I pretty much only use it for short statements. Not trying to attack your way of scripting, we all script differently. I’m just stating my opinion. I see where you’re coming from.
I use both of them but I definitely like to use the second one. I try to nest as little as possible so I have quick conditionals to eliminate bad arguments or incompatibilities.
Practically speaking, the one-liners are perfectly fine, and there is no real effect on performance.
However, I personally prefer the if statements to be broken up into multiple lines for readability.
If you want to stick with the one-liners, you may want to look into Ternary Expressions:
I say you should always use this one. Only excuse can be:
local x = if y then false else true
on some cases which you cannot fix with and, or. If block still valid but will add more than 3 lines for a simple thing. Multiple statements per line can get bad very fast.
While I agree multiple statements per line aren’t great, it’s more clear when you use number two sometimes and it helps to eliminate errors before they exist.
An example of this:
game:GetService("UserInputService").InputBegan:Connect(function(input, gpe)
if gpe then return end
--Now, you know gpe is false and the input is good to be processed normally, so you can eliminate this as a possible cause of issues/errors.
end)