I've been told on several occasions that it's a real NO NO to ever have a simple
return;
without at least setting a 0 value to it.
Even if the calling program never reads the return value, perhaps it's still a wise thing to do?
Fair enough, but what's the correct way to terminate a program rather than a function?
I've seen lots of scripts with return; in the program body, but maybe we should be using exit; instead? Does it matter in the slightest? Not that I've seen exit documented.
I also find it curious that program/endprogram statements are in fact not necessary to compile a script - ie ecompile doesn't generate any errors.
Or even that you can put a ; at the end of the if() line or not. Compiler doesn't care.
Sorry to bring these up, it's been in the back of my mind for years but I never got around to checking up on them before.
Use of "return;" and other little oddities
This is just my take on it:
It's like, in C, when you write:
It lets you know that you actually DO mean to pass ( or in this case, return ) a blank value. That just makes it easier to read "at a glance" by yourself AND others.
Another reason is that it provides a certain level of consistency between scripts that a return DOES matter, and scripts that a return DOESN'T matter in. Some scripts return a value to the core, and depending on the value they return, the core will perform a different set of actions, or no action at all. In this case, you NEED to know what your passing. You can pass return; to the core, and hope it's interpreted as 0 every time- but then why not just pass return 0; and be sure? This isn't nessessary in all scripts; in fact, it's completely irrelevant in most scripts.
So, in short, it's not that it's wrong or evil so much as it's "frowned upon as improper". It doesn't matter that often, and more-or-less parallells the idea of using void main() instead of int main( ... ) in a program.
It's like, in C, when you write:
Code: Select all
SomeFunction( void );Another reason is that it provides a certain level of consistency between scripts that a return DOES matter, and scripts that a return DOESN'T matter in. Some scripts return a value to the core, and depending on the value they return, the core will perform a different set of actions, or no action at all. In this case, you NEED to know what your passing. You can pass return; to the core, and hope it's interpreted as 0 every time- but then why not just pass return 0; and be sure? This isn't nessessary in all scripts; in fact, it's completely irrelevant in most scripts.
So, in short, it's not that it's wrong or evil so much as it's "frowned upon as improper". It doesn't matter that often, and more-or-less parallells the idea of using void main() instead of int main( ... ) in a program.
-
Marilla
Re: Use of "return;" and other little oddities
I would wonder if there's some specific eScript reason that it's better to slap a 0 at the end of that return;...OldnGrey wrote:I've been told on several occasions that it's a real NO NO to ever have a simple
return;
without at least setting a 0 value to it.
Even if the calling program never reads the return value, perhaps it's still a wise thing to do?
Other than that, though, my only thing is to keep it consistent; if a function truly returns no value, and -NEVER- returns a value, I don't see the harm. In practice, I usually don't end up with many plain return;s without some value, because at minimum, I end up returning a success/error value (thinking HRESULT?)
But for very simple functions that do something, and where any 'error' condition would be truly irrelevant, I do a return;, or simply let the function fall through (which I assume has the same result).
Essentially, I look at a function 'falling through' or exiting with 'return;' as a void function. Certainly void functions are not 'huge no nos' - though again, you might often want to return some sort of status code from the function.
(Just for the record, too; for those not aware, When I say 'void function', I do not at all mean the same thing SMJ is referring to. SMJ's "SomeFunction(void)" is a function that has no parameters and uses the 'void' term simply to make that explicit, where a void function is one that returns no value.)
I'd be interested in knowing if there was some eScript-specific reason for this suggestion, though.
Again, I'd be interested in knowing if there's a 'best practices' way to do this that is based on some objective situation in eScript. Personally, I look at 'Programs' as simply a function that happens to be something of an 'entry point' to the script - sort of like it's an "int main()"; it's just another function, but it has a special relationship with the environment because it can be called from outside of the unit of script code in question.OldnGrey wrote:Fair enough, but what's the correct way to terminate a program rather than a function?
But in this case, the return value is usually not important. I should add, "to me"; because I have eliminated "run_script_to_completion()" calls from my shard entirely; For me, most 'programs' might as well be void functions, and I treat them as such. Obviously, system hooks and such are a different story.
Code: Select all
var something := SomeFunction();
function SomeFunction()
return;
endfunction
Code: Select all
var something := SomeFunction();
function SomeFunction()
return 0;
endfunction
The second approach is done in the distro because it keeps the values safer to use. It has a more predicable outcome if something catches the return value from a function and later tries to use it by copying it to another function or using it with some sort of operator.