Return usage in a Function

[bo8ster]

I believe what Valik demonstrated was an Implicit Return value should be the same as an implicit End-Of-Function return value. And I would agree with consistency of return values in mind.

The craziness is to do with the readability of the code. Most ppl would have to run the code to figure out what is going to happen. AutoIt protects you here, other languages would not.

If Not ReturnImplicit() Then
    ConsoleWrite("foo")
Else
    ConsoleWrite("bar")
EndIf

Func ReturnImplicit()
    ; do something
EndFunc

[JRowe]

Having an explicit return "just because it looks better" doesn't make sense to me. For what I'm doing, wrapping a few hundred DLLCalls, the only error handling and debug code would be returns of @error and @extended. I'm not quibbling with low level constructs. I'm creating a function that will either work, or something is catastrophically wrong - a parameter was incorrect, the dll wasn't in the correct directory, the large hadron collider destroyed the hard drive... something out of the purview of the function.

It saves me time to not add those to every function. The docs for those functions contain all the background needed to understand what they're doing, and the variable names gives the information necessary to figure out the overall context.

For example:

Func _IrrSetSphericalTerrainTexture($h_Terrain, $s_Top, $s_Front, $s_Back, $s_Left, $s_Right, $s_Bottom, $i_MaterialIndex)
    DllCall($_irrDll, "none:cdecl", "IrrSetSphericalTerrainTexture", "ptr", $h_Terrain, "str", $s_Top, "str", $s_Front, "str", $s_Back, "str", $s_Left, "str", $s_Right, "str", $s_Bottom, "int", $i_MaterialIndex)
EndFunc ;==>_IrrSetSphericalTerrainTexture

There's nothing that function returns. It sets the parameters of a struct created and managed entirely by the dll. It doesn't return any error codes. I could, for every function, add a conditional to test whether each parameter was of the correct type. Imo, that's a waste of space and time.

I could just assume that the user will look at the docs and say "oh, I need to pass a pointer to texture for each $h_", or pass a filename for each $s_ in the function. If the function works, then a Return would be superfluous. If the function fails, Scite is going to tell me at what function things went wrong, and there's really not much more information that's necessary to fix any issues that come up.

Edited May 3, 2010 by JRowe

[MHz]

The craziness is to do with the readability of the code. Most ppl would have to run the code to figure out what is going to happen. AutoIt protects you here, other languages would not.

I see no reason to disagree. I am going to play it safe. Mentioning other languages is like entering the abyss as far as syntax etc. goes so I do not want to go there in this topic.

Having an explicit return "just because it looks better" doesn't make sense to me.

If most UDFs use it, then doing the rest of them seems consistent. I do not do it for pride but as an insurance that any UDF will Return 0 or will Return "" as for usage requirements. Both returns will boolean fine using "If <function call> Then" but when using them literally for output for errors, logging etc, then it does have advantages.

For what I'm doing, wrapping a few hundred DLLCalls, the only error handling and debug code would be returns of @error and @extended.

If you are using SetError() then you could add a return value easy if you wanted. Notice the choice I give as I am not dictating at all of how you code. You choose your own path as it suits. I have mentioned my habits to express what I do and I am not rigid to do every script such a way if it seems more of a waste of space as you mention. I do not consider the term "a waste of space" for every script in general is suitable or correct to state for my scripts.

Thanks for your last detailed response explaining your interests.

[JRowe]

Absolutely, I don't want to be too generic - 99% of my functions are going to get a Return, but there are valid cases when it's just extraneous. Your biggest point, though, is "habit."

It would probably be ideal to be in the habit of always Returning something.

[bo8ster]

Having an explicit return "just because it looks better" doesn't make sense to me.

I totally agree. I see only two options when using return, either return a value that is useful or leave the return out and let EndFun do terminate the function. Not all functions are required to return anything, example being print usage or a console program. The only time I can think of where return with no value might be valid is with recursion but that is different.

@Mhz - yes, lets stay away from the abyss.