From a coding elegance standpoint, Yes. But one-liners don’t always help the learner, especially those for whom the abstractions of coding are quite alien. Using a variable in this context is moot as the whole point was to contract use of attribute vs use of variables†.
Pre-declaring variables does have some use:
It can be clearer to a learner that a variable (optionally of a :type) is being created. One-liners can be obfuscatory for the user. The more recent ability to declare and set a variable using = rather than function-like in trailing parentheses does make this terse form more accessible to non-programmers.
For general use for a variable to be available outside a loop, it needs to exist before the loop is entered. So, it needs to be declared as an empty (option :type) variable before the loop is called.
†. Yes, use of attribute and variables for value storage in a function can be mixed, but I’m trying to avoid diversion onto a side-quest here.
Some N00b Qs here, sorry… seeking clarity about the role and usage of “return”.
when we command a “return”, where exactly is that result being returned? I’m assuming to wherever the function has pointed it, but is it also a value that floats around within the project file until reset?
=============
if we issue a “return”, and if the very next line is a reset of the value wherever it is stored, then how do I see it? Isn’t it necessary to store the result somewhere in order to see or utilize it?
In my head, the play-by-play is:
function is triggered
result is returned (where? To specified location, or saved as an Attribute’s value, or a component of that value)
function immediately resets value (But I was distracted, and didn’t see the result! I guess I need to run the function again).
and if $Xpos is 1 and $Ypos is 2, the final value of $Coordinates remains as “(1,2)” because the last line of the function is not processed because it comes after the return operator’s line of code.
Thus, return actually has two effects:
it sets the function’s output it the code on the rest of the line starting return.
it terminates the function.
I’ll add some documentation that return, if used, must be the last line as I don’t think that’s yet been mentioned before. Though perhaps obvious after the fact, it’s unlikely to be guessed by users without a programming background.
I’m sorry if I appear unintentionally obtuse. I think what’s emerging is a gap of expertise-based assumptions as to general user knowledge. @archurhh’s question seem unsurprising in that context. But, no foul here, I’m simply (in my volunteer documenter ‘hat’) trying to fill the un-guessable gaps in the current docs. I’ve more aTbRef content on the stocks at the moment, but I’m not suggesting that be the only place this is described. Perhaps, when the things settle post v9.1.0 that we could use these questions to make an additional explanatory PDF for the Help menu covering functions.
We test n<=0. That’s false, so we ignore the expression in brackets.
We next test n==1. That’s true, so we return the value 1.
As we have returned from the function, the next line, return fib(n-1)+fib(n-2);, is not executed and has no effect.
That still avoids a clear yes/no answer, so as to be unambiguous for learners. But, by inference, if used returnmust be the last line of code in the function. Any (additional lines of) code after the return line are never executed. Indeed, if there is a lot of commenting, that may be a good place to put it so that when viewing a function the reader does have to do lots of scrolling to get to the code. A single comment at start can signal that longer comment lies further down.
“line” may be the wrong expression. If executed, return will terminate a function - no matter where return has been placed.
Other language offer an exit command too - again this would leave the function.
I think using exit or return in the middle of a function (in a conditional statement) is not the best style. So:
function fib(n) {
var myResult = 0;
if (n<=0) {
myResult = 0;
} else {
if (n==1) {
myResult = 1;
} else {
myResult = fib(n-1) + fib(n-2);
};
};
return myResult;
}
is the way to avoid a return before the end of a function. But this is a question of your personal preferences - readability is important…
By the way - recursive functions can crash an app very easily
Perhaps it’s more understandable to say that after a return statement is executed, no further code is run in the function. With the if statement fib(n) example above, when n=2, then the first two tests are not successful, so the returns aren’t executed, and so the code continues to the 3rd.
Probably only in the case of if statements would you have more than one return. However, you could have an if statement that only has a return if true and then false may not return anything but still does something, e.g. change an attribute. e.g. return a number but if not then make the note red.
When I read:
The return operator is only used inside a function and if used is used only once per function operator call.
– Source
To me it sounds like you are only allowed one return statement in the function. i.e. the word can only appear once. Which isn’t true, but of course that is just my reading of it. I mention it as perhaps others might draw the same conclusion.
Understandability is paramount. In general, a single return at the bottom of a function is the clearest, and most desirable. However, there are cases — especially in deeply nested structures — where a simple return is the most clearest expression of intent. This is particularly true when compared to the necessity of having to introduce state variables just to keep track of what has happened earlier in the control flow in order to affect what happens later. But like most things in computing (and programming in particular), it depends.
