Such a thing a too many arguments?

[Guest]

Is there such a thing as passing too many arguments to procedure? I have a
function with seven. Would it be better to pass just one unique value and
look up the rest when the procedure runs?

 

[Guest]

If you already have the values, it better to pass them to the function, there
is no need to perform a search on values you already have.
That way you save on time, resources, code line, and defenitly maintnance
time later on.
I don't know what is the limit for parameters you can pass to the function,
but if you already have the values, pass them on.

 

[sebthirlway]

As Ofer says, it's better to pass the values to the function than look
them up again - more efficient. "if you already have the values, pass
them on" - can't argue with that!

But it might be useful to think beyond this particular call to the
function, where you already have the values - if the function is likely
to be used again and again in different contexts. If
the input values are only being looked up by the calling code for the
purposes of calling the function, then it _might_ be better to redesign
things so that you can just pass the unique value and let the function
handle all the rest.

It's one of those hard-to-answer questions, where the answer depends on
the precise circumstances. If I write a function that uses seven
arguments it looks wrong/messy, I feel sure that there must be some
better way of doing it - even though I've never come across any
performance/stability problems using functions with lots of arguments;
but then again, I've often ended up deciding that a function with lots
of arguments _is_ the best way of doing it.
Things to consider:

a) Is the function so wide-rangingly useful (to take a simple example,
a function which looks up an organisation ID and returns the
organisation's name) that it's likely to be called many times? If yes,
having to code the calling procedures to run about and collect all the
values each time will turn out to be a right pain.
b) Does the function encapsulate some important business logic? For
example, an IsEmployeeEligibleForFamilyTaxRelief() function - which
might depend on 27 different factors (age, gender, marital status,
income, number of dependents, employment status). This type of
function, IMHO, is best designed to take just one key value as input,
and look up the rest.
c) Are the values particularly difficult to look up or calculate? Do
you get a noticeable performance hit looking them up twice?

I've just realised that what I say in (b) contradicts the principle of
three-tier architecture, where the business logic and data access are
to be kept separate - this is a murky area, and I'm sure that lots of
people (if they care to) could point out other circumstances where what
I say doesn't apply.

One thing I've found useful to avoid having a whole lot of separate
variables floating about is to declare a user-defined type, and pass
that around code from function to function. Or use a class, for more
complex work.

cheers


SEb

 

[Brendan Reynolds]

Why do you ask? Are you having a problem with the function as it is?

One possible alternative is to pass a UDT (User Defined Type) or custom
object. Here's an example using a custom object ...

In a class module called clsTest ...

Option Compare Database
Option Explicit

Private mPropOne As Long
Private mPropTwo As Long

Public Property Get PropOne() As Long
PropOne = mPropOne
End Property

Public Property Let PropOne(value As Long)
mPropOne = value
End Property

Public Property Get PropTwo() As Long
PropTwo = mPropTwo
End Property

Public Property Let PropTwo(value As Long)
mPropTwo = value
End Property

In a standard module ...

Public Function TakesCustomObject(TestObj As clsTest) As Long
TakesCustomObject = TestObj.PropOne + TestObj.PropTwo
End Function

Public Sub TestTakesCustomObject()

Dim lngOne As Long
Dim lngTwo As Long
Dim objTest As clsTest

lngOne = 1
lngTwo = 2
Set objTest = New clsTest
objTest.PropOne = lngOne
objTest.PropTwo = lngTwo
Debug.Print TakesCustomObject(objTest)

End Sub

 

[Guest]

Thanks for all your replies, it's given me a lot to think about. The only
reason I ask is because, as suggested, it looks very messy having three lines
of arguments at the top of a function, and it makes revising very difficult
to read at first glance.

 

[John Nurick]

I'd use seven lines of arguments instead, and consider delcaring some as
Optional so there's no need for the calling procedure to pass default
values:

Const DEFAULT_CARRIER As String = "QF"

Public Function MyFunction( _
Passenger As String
Origin As String, _
Destination As String, _
Optional Carrier As String = DEFAULT_CARRIER, _
Optional DietaryRequirements As String = "None"
...)