PROC or FN?

[MattC]

Hi,

The difference of use of a procedure or a function is often obvious.

If you need to do something without a return, then a procedure is applicable. If you need a result that a function can give, such as one that returns a square root or a TRUE/FALSE return, you can incorporate this into the command, e.g. PRINT 2 * FN_squareroot(4). However, if the result is not needed to be incorporated, then both can be used:

Code: Select all

sqr = FN_squareroot(4)
PROC_squareroot(sqr)

DEF FN_squareroot(n)
= SQR(n)

DEF PROC_squareroot(RETURN n)
n = SQR(n)

My question is, which is better when there is no reason to incorporate the answer directly within a calculation or condition? Are there any rules (of thumb) that one could use to determine the best course? Is there a time consideration? I realise that this may all depend on the individual circumstance, but a general idea would be useful.

Matt

[DDRM]

Hi Matt,

In the end, it's a matter of preference to some extent. I'd generally use a procedure if I don't want to return a value, or if I need to return more than one value (by using RETURN parameters).

In the latter case there's no reason I know of why you couldn't use a function and return one as the result of the function and the other(s) as RETURN parameters - but that feels a bit "misleading" - a function should return a result, not hide some of its actions!

If the point of the subroutine is to return a (single) value, I'd use a function, to make this obvious - it also means it can be used directly in a calculation:

hypotenuse = FNRoot(FNSquared(a) + FNSquared(b))

to give a silly example...

As an aside, in Python you can return multiple values from a function...

One gotcha / opportunity to be aware of is that you can pass arrays and structures to procedures and functions, but they are passed by reference - so if you modify the values inside the routine it WILL modify the value outside the routine. It's as if they automatically had RETURN prepended to them.

Hope that's helpful!

D

[MattC]

Helpful and valuable as always.

My feeling are similar. When I have written library routines that require more than one return value, I have mainly used procedures, using functions for singular. However, I have also use functions with 'RETURN' values where these are of far less use than the direct return. For example, one function returns the pixel length of a printed string (which, in my case, is far more useful than the height). However, the height of the string is 'RETURN'ed through the parameter as an optional extra - the FN being far more 'intergratable' than the PROC.

Thanks again for your thoughts.

Matt

[DDRM]

One other reason for returning a value as a function even when you don't really need it is as a check that the function succeeded - for example, returning 0 (equivalent to FALSE) if it failed for some reason, and -1 (TRUE) if it succeeded.

D

[KenDown]

There are several circumstances in which FN is preferable. One is the use of EVAL. In my Display program I made it possible for the user to create and incorporate his own graphics routines as a library of functions. Each presentation is a text file and is read in as a sequence of strings. One line of a slide might read "|C9Title", which would display the word "Title" in bright red (COLOUR9) and the next line might read "|NFNscroll(20,2)" where the function will scroll the screen by 20 steps of 2 pixels each. The parser has this line:

Code: Select all

temp%=EVAL(MID$(sl$,3))

MID$(sl$,3) strips away the "|N" and the EVAL invokes the function, which does the scrolling and then returns a dummy value of zero.