Should you use early return in roblox lua?

[Skidouski (caseoh)]

Hi so I have been wondering, would you guys say its cleaner and more readable to use early returns in Roblox lua. From what I have googled and found, some people prefer early return because it in a way validates the values passed into the function first, and then it gets that out of the way from the code. Another thing is if you should do the same thing with loops. For instance in the example below I use continue in a similar fashion of using return, but just skipping the current loop. I am very interested in hearing you guys thoughts on these so lmk what you think

Early return

local function earlyReturnExample(partUnixLifeTime, player)
	if not partUnixLifeTime or player then
		return
	end
	for x = 1,10 do
		local buildingBlock = game.Workspace:FindFirstChild(tostring(x))
		if not buildingBlock then
			continue
		end
		buildingBlock.Colour = Color3.fromRGB(255,0,0)
		buildingBlock:SetAttribute("partUnixLifeTime", partUnixLifeTime)
		buildingBlock:SetAttribute("player", player)
	end
end

No early return example

local function noEarlyReturnExample(partUnixLifeTime, player)
	if partUnixLifeTime and player then
		for x = 1,10 do
			local buildingBlock = game.Workspace:FindFirstChild(tostring(x))
			if buildingBlock then
				buildingBlock.Colour = Color3.fromRGB(255,0,0)
				buildingBlock:SetAttribute("partUnixLifeTime", partUnixLifeTime)
				buildingBlock:SetAttribute("player", player)
			end
		end
	end
end

[Benified4Life (Sekonds)]

Early returns can be good if used in the correct way. If you use dynamically typed code for a function in luau, returning early doesn’t cause too much trouble. However, there are a few downsides to returning early, such as the procedure/function makes debugging more troubling.

Imagine you do use early returns and have a function, say local function isAPrime(number). From a function like this, you’d expect to receive a boolean response. If you chose to use an early return when a valid number isn’t provided, or a number isn’t provided at all, the function will return [false]. There is no way to distinguish this false from one of which a valid input, say 20, would provide.

Now why is this a problem? When you’re debugging your code, you’re likely to be looking through quite a few lines, each of which you’d assume to do as expected without missing parameters, variables, etc - after all, this is a logical error and not a syntax error. You may have also written these functions weeks or months ago, so you have to assume each function does as expected, otherwise you’ll be looking through even more code. If you have, by chance, forgotten to pass an argument into a function, you would be none the wiser, however you’ll always receive false returns.

Aside from that issue, when using statically typed code, you cannot just “return”; you need to return a value specific to the expected return type. For example, if you had a function to rotate a vector n degrees about the line x = 0, and the user forgets to pass in the amount to turn, what would you return? Would you assume n = 0 and return the vector passed in? Or maybe you’d return a blank vector, to make it obvious there was a mistake?

Personally, I use early returns; just be careful when and where you make use of them.