A code style question

[Ben Rubinstein]

On 21/01/2015 15:53, Geoff Canyon wrote:
> the obvious drawback of the way it is now is that both outcomes have
 > to be evaluated, where in an if statement, obviously, only one of them is.

True, but (coding style preference) I tend to use it pretty much only for 
constants.  If there's a complex expression in there, I prefer to split it out 
onto lines where there's more whitespace around the expressions to help 
future-me comprehend the code!

Of course there's a speed penalty to using a function in this way (though 
there wouldn't be if it was built in*) - generally I'm using it to make the 
code more readable, to avoid the eye+mind tripping over a big expression 
that's only doing a simple thing, when it will be more comprehensible as e.g.
	set the spotcolour to ifte(status="good","green","red")

To my mind, that makes it more obvious how limited this issue is - I can 
quickly see that this is just about setting red or green according to the 
status - whereas the five line
	if status = "good" then
		set the spotcolour to "green"
	else
		set the spotcolour to "red"
	end if

forces me to read it more carefully to check whether there are other actions 
being taken depending on the condition, whether it's the same property being 
set in both, etc.

Ben
	
*Sorry, I've only just realised as I was about to press send that the point 
you were making was that if it was built-in, then it also wouldn't need to 
evaluate both outcomes.  Good point - though I'd personally still tend to 
restrict the use to constants or very simple expressions.