[AccessD] Function vs Sub (was: Classes and Events - EVENTS NOT REQUIRED)

Hi Lambert

Mysterious? Strange argument you have here:

If you don't know what a subfunction does, don't use it.
If you don't know what a function does, use it anyway.

Strange logic to me.
If you have problems understandig or debugging the operation of a subfunction, this won't change if the change the subfunction to a function.

Also, the hypothetical sub RoundAmount was just an example for everyone to understand. That said, the scope of rounding is much wider than for display. For example, anyone dealing with systems for invoicing and accounting will know how important careful rounding is.
Rounding is also very important for timing purposes. Examples of this can be found here in the article by Susan and me:

  http://www.devx.com/dbzone/Article/39046 

/gustav


>>> Lambert.Heenan at aig.com 24-02-2009 19:24 >>>
I also favor using *real* function calls.

I especially don't like subs mysteriously modifying data. The example given was

RoundAmount curAmount, 2
Debug.Print curAmount   ' Returns 12.35

Here we have a Sub that is modifying its input parameter curAmount, but the only way to rally know this is by examining the source code of the Sub, which may not be available to you. One might say that the fact that the sub is Named "RoundAmount" tells you what it's going to do, but even that's not really the case. The RoundAmount sub is doing more than just rounding. I'll stick my neck out and say in most cases where rounding is done it's because you want to *display* data at a certain precision, but the underlying data should remain unchanged.

So  curRounded = Round(curAmount,2) does just that, we get a rounded value to display, and curAmount does not alter.
Whereas RoundAmount curAmount, 2 is throwing data away.

My 2 cents.

Lambert


-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, February 24, 2009 1:04 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Function vs Sub (was: Classes and Events - EVENTS NOT REQUIRED)

In that case I prefer the function returning a value, because the = tells the mind that a value is coming back.

John W. Colby
www.ColbyConsulting.com 


Gustav Brock wrote:
> Hi Charlotte
>
> No, you are right, that is seldom.
> However, a sub may call(!) for more elegant code.
>
> Instead of:
>
>   curAmount = 12.345
>   curAmount = RoundAmount(curAmount, 2)
>   Debug.Print curAmount   ' Returns 12.35
>
> then this:
>
>   curAmount = 12.345
>   Call RoundAmount(curAmount, 2)
>   Debug.Print curAmount   ' Returns 12.35
>
> or even:
>
>   curAmount = 12.345
>   RoundAmount curAmount, 2
>   Debug.Print curAmount   ' Returns 12.35
>
> Still a matter of taste, I guess.
>
> /gustav
>
>>>> cfoust at infostatsystems.com 24-02-2009 18:24 >>>
> Absolutely when you need multiple return values, but a simple boolean
> or single value?
>
> Charlotte Foust
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com 
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav
> Brock
> Sent: Tuesday, February 24, 2009 1:45 AM
> To: accessd at databaseadvisors.com 
> Subject: Re: [AccessD] Function vs Sub (was: Classes and Events -
> EVENTS NOTREQUIRED)
>
> Hi Charlotte
>
> Not tidy? In some cases this feature is very useful.
> Here is a simple example of sub returning multiple values:
>
> <code>
> Public Sub CompositeRGB( _
>   ByVal lngRGB As Long, _
>   ByRef intRed As Integer, _
>   ByRef intGreen As Integer, _
>   ByRef intBlue As Integer)
>
> ' Calculate discrete RGB colours from composite colour Value.
> '
> ' 1999-08-20. Cactus Data ApS, CPH
>
>   If lngRGB < 0 Then
>     ' Nothing to do.
>     intRed = 0
>     intGreen = 0
>     intBlue = 0
>   Else
>     ' Dissolve composite RGB into discrete colours.
>     intRed = lngRGB And vbRed
>     intGreen = (lngRGB And vbGreen) / &H100
>     intBlue = (lngRGB And vbBlue) / &H10000
>   End If
>   Debug.Print intRed, intGreen, intBlue End Sub
>
> </code>
>
> The only reason I see to not write a sub when a return value is not
> needed, is if the (sub)function will be used in a macro as these can't
> call subfunctions.
>
> /gustav