Return usage in a Function

[GEOSoft]

Someone else and I have tossed this around for a few minutes now and we don't have definitive answers other than the possibility that it will somehow prevent or at least limit Recursion and/or release any pointers.

When there is no value to be returned from a function, what is the reason for adding an empty Return or is there no difference at all?

Func SomeFunc($sVal)
    ;; Now do something with $sVal
   Return $sVal
EndFunc

Makes sense

Func SomeFunc($sVal)
   Return
EndFunc

Is the one that needs explaining

Just being "Curious George" again

If it needs more explaining, I can post the function that started the discussion to begin with.

Edited April 30, 2010 by GEOSoft

[Valik]

It's done for the same reason people add "Exit" to the end of their scripts. People apparently like seeing useless statements in their code.

[GEOSoft]

It's done for the same reason people add "Exit" to the end of their scripts. People apparently like seeing useless statements in their code.

Just so we are clear then, There is no reason for it at all and my assumption that it's redundant code is valid?

[James]

George,

I use it like that sometimes when I first write a function, I can keep track of where my code is leaving the current function, then jumping back out to its main procedure.

@Valik, if that's the case - it being pointless - why do I commonly see it in the help file examples, sitting there, on its lonesome?

James

[bo8ster]

It's done for the same reason people add "Exit" to the end of their scripts. People apparently like seeing useless statements in their code.

+1 What James said - it is in the help file but it does serve a purpose as Exit(0) is the default. This is required when working with other tools such as continuous integration tools to assert if the program finished without error or not. Same as int main(void) {return (0)} in C.

Return is useful in recursion however there is no point to return nothing just before EndFunc as shown.

[MHz]

Just being "Curious George" again

George, Why did you put quotes around "Curious George"? My Answer: IMO, to express visually that is important or something similar.

I am guilty for using an explicit "Exit" or even an explicit "Return" value.

I use an explicit "Exit" as it flags end of direct executable code as Valik mentioned for a visual reason. I also do it as I can cut and paste code out of the main script and put it below "Exit" and substitute it with perhaps more efficient code for testing. So, I prefer seeing "Exit" and the fact that anything should not execute below it unless a function call happens for those functions below the "Exit".

I use an explicit "Return" since the default behavior changed form an empty string to 0. That change can be a script breaker so I now ensure that the "Return" value is what I expect by using an explicit "Return".

I am also explicit with using quotes around paths that may contain whitespace. The amount of times that people in the support forum are caught out by not using quotes is huge. The extra effort does help to use quotes else expect scripts to fail at unexpected times.

I consider the above as good habits. Anyone can adopt them. People usually need to learn from their own mistakes before they heed caution, which is fine, as I tend to do the same at times.

[GEOSoft]

I used it as a way of empasizing an old habit really. Back in the days before our sigs were attached to PMs I would often send Valik, or Jos or others a PM that was signed

Curious George

Senile George

Crazy George

or whatever and it really indicated the level of importance I put on the question. For instance Curious George is pretty well the same as saying Just curious.

As for Exit, I use it for the same reason you do, testing, but it does eventually get removed. I was only using Return where I had an explicit value to be returned and I wondered if there was a valid reason for using an empty Return statement in a function. It appears that Valik has given the definitive current answer and I also accept that this may not have always been the case.

There are also other functions that some people use on a consistant basis that I don't bother with although perhaps i should be. GUIDelete() When exiting the script is one such case. Of course I do use it when it's required as in the case of multi-GUIs.

[Valik]

@Valik, if that's the case - it being pointless - why do I commonly see it in the help file examples, sitting there, on its lonesome?

Don't get me started on the examples. I think most of them are terrible. They show how to use a function but they do not show proper coding techniques.

I use an explicit "Return" since the default behavior changed form an empty string to 0. That change can be a script breaker so I now ensure that the "Return" value is what I expect by using an explicit "Return".

When did it ever return an empty string?

[MvGulik]

whatever Edited February 7, 2011 by MvGulik

[MHz]

When did it ever return an empty string?

Sorry if I misled you or anyone else. I should have specified the default return value at the end of a UDF was an empty string and later changed to 0. I can see now what I previously typed could suggest the default return value of using "Return" itself changed between AutoIt versions which IIRC has never changed. I hope that I expressed better this time.

[Valik]

I knew what you meant - I think. My question still stands, when did the implicit end-of-function return ever produce an empty string?

[MHz]

I just tried AutoIt 3.0.102 and AutoIt 3.1.0. These seem to return 0 but IIRC it was related to a COM bug report and a change happened. COM was added as per AutoIt history in 3.2.0 so it may have gone from earlier 0 to bugged "" to later 0 again as a bug correction. It may have been a time when internal UDF code was being improved. I know at the time it initiated me to use an explicit "Return" with a value at the end of all UDFs to ensure I received the value expected.

[Valik]

These two functions should return the same thing:

Func ReturnImplicit()
EndFunc

Func ReturnExplicit()
    Return
EndFunc

If they ever don't return the same thing then it's a but.

[Richard Robertson]

I think the real problem here is that you're trying to save a value from a function that did not return one.

[Valik]

I think the real problem here is that you're trying to save a value from a function that did not return one.

This statement is demonstrably false.

[Richard Robertson]

This statement is demonstrably false.

Fine, I'll be explicit.

No explicit value was returned, therefore leaving the value up to the internals of AutoIt to decide.

[bo8ster]

These two functions should return the same thing:

Func ReturnImplicit()
EndFunc

Func ReturnExplicit()
    Return
EndFunc

If they ever don't return the same thing then it's a but.

According the help file "Use the Return keyword to exit the function. Unlike built-in functions, user-defined functions return 0 unless another return value is specified."

So using only the provided code there is no use having the return but when used with other code and can be useful for error handling.

If ReturnExplicit() <> 0 Then
    ; do something
Else
    Exit(2)
EndIf

Func ReturnExplicit()
    ; do something
    Return
EndFunc

As pointed out, such a practice is very poor since the return value is not specifically specified, you have to know and trust that it will be 0. Any sane programmer would put 'Return 0'.

I think it comes down to knowing what you are doing and knowing what effect each line in your code does.

Edit: I would consider it crazy to use Valik's ReturnImplicit function in my example even if it works, you might was well use gotos.

Edited May 3, 2010 by bo8ster

[JRowe]

What about passing a value ByRef to be modified by the function, without needing anything more:

Func _ChangeText(ByRef $s_SomeString)
    $s_SomeString = "String Changed"
EndFunc

It's simplistic, but I don't know that there would be any value, other than explicit debugging, to adding "Return 0" or even "Return" to this snippet. Isn't AutoIt's speed dependent on the number of characters it processes? It would then make sense to want to reduce your code to the fewest number of lines possible.

Also, I'm using DllCall functions such as "setNodeColor." It takes a Node and a Color, then sets the value for that parameter. There is no return value. Again, there's no value in Return aside from explicit debugging, which would just waste space (if one function doesn't work, they're probably all broken.)

"Get" type functions need returns. "Set" type functions don't need them.

;usage would be
_SetText($h_Edit, "This doesn't need a Return Value")
Func _SetText($h_SomeControl, $s_SomeString)
    ;Set the Control Text here
EndFunc

Edited May 3, 2010 by JRowe

[MHz]

As pointed out, such a practice is very poor since the return value is not specifically specified, you have to know and trust that it will be 0. Any sane programmer would put 'Return 0'.

Hey, I like how you comprehend.

Edit: I would consider it crazy to use Valik's ReturnImplicit function in my example even if it works, you might was well use gotos.

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.

What about passing a value ByRef to be modified by the function, without needing anything more:

I do a lot of error checking and value handling in my scripts. Some times I do think twice about adding a explicit Return value though I normally follow the behaviour I have chosen for consistency.

It's simplistic, but I don't know that there would be any value, other than explicit debugging, to adding "Return 0" or even "Return" to this snippet. Isn't AutoIt's speed dependent on the number of characters it processes? It would then make sense to want to reduce your code to the fewest number of lines possible.

I do a lot of error handling as mentioned and I do not like debugging so I make scripts very verbal in notifications of error conditions and information.

Calling a UDF has an overhead, so where do you draw a line on speed. Readability of code is more important to me in general then fast code that is a PITA if it is hard to read and hard to debug. In areas like tight loops you may need to keep error handling etc to a minimum if you want speed but the rest of your script should not suffer the same treatment.

Also, I'm using DllCall functions such as "setNodeColor." It takes a Node and a Color, then sets the value for that parameter. There is no return value. Again, there's no value in Return aside from explicit debugging, which would just waste space (if one function doesn't work, they're probably all broken.)

I use the value from Return often so waste of space seems extreme to state. All functions broken sounds extreme also.

"Get" type functions need returns. "Set" type functions don't need them.

It depends on what you consider by need judged by their use and how often they are used. So the need is a variable in theory terms.

[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 ReturnExplicit() Then
    ConsoleWrite("foo")
Else
    ConsoleWrite("bar")
EndIf

Func ReturnExplicit()
    ; do something
EndFunc