Re: Function versus Procedure

David, we are in the realm of stylistic choices, so I hope you can respect that others may make choices for reasons other than the ones that make sense to you.

To me it makes no sense to start it out as a Sub when we don't know for sure that it will never be used in an event property, and we don't know for sure that it will have no return value. There's also an inconsistency in the way VBA calls subs and functions, so if everything I create is a function, I don't have to remember whether it was a sub or a function in order to call it. To me, it makes the code simpler to create and to maintain if I know all my proc's are functions. There are just fewer things that can go wrong (e.g. in calling, or in using it in an event property.)

I do tend to assign a return value anyway, even if it's no more than a success/failure flag, or a count of the records affected/matched.

(I think you'll find that a function that does not declare or return any type yields Empty rather than Null, through I understand this is not something you ever do.)

Call me sloppy and a bad coder if you wish; to me, declaring everything as a function is not the same as the issue of whether it has a return value, it's just more consistent coding and less problematic in the way it's called. One could even suggest suggest that having both is unnecessary complexity, and Subs should be dumped (a kind of Occam's razor.)

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.


"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message news:Xns9C7EB1B211A60f99a49ed1d0c49c5bbb2@xxxxxxxxxxxxxxxx
"Douglas J. Steele" <NOSPAM_djsteele@xxxxxxxxxxxxxxxx> wrote in
news:OxtfH3uLKHA.504@xxxxxxxxxxxxxxxxxxxx:

"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
There are times when it's convenient to use =MyFunc() as the
property for an event.

When I'm going to do that, I'll create it as a function. When it's
clearly not going to be used for an event, there's no point, in my
opinion, in making it a function.

Also, I find this kind of code

Public Function MyFunction(varParameter As Variant)
[code the does something]
End Function

...to be highly objectionable.

1. it doesn't declare a return type, so defaults to Variant.

2. there is no assignment of the return value, so it returns Null in
all cases.

I believe that it should be an ironclad rule that:

1. all functions should have a declared return type.

2. all functions should set the value of what is returned.

In my opinion, functions used as events, as you describe, should
return a Boolean, even though the return value is completely ignored
by the form's event handler.

The alternative is

1) setting the property to [Event Procedure]
2) put a single line of code into the sub that's generated to call
the common sub.

for each control.

I've got forms with 300 controls on them where each control calls
the same code (think of it as a seating plan, where each control
represents a particular seat, and I want specific code to run for
each control when particular events, such as GotFocus, LostFocus
or DblClick, occur.). Using subs instead of functions would be a
LOT more work to set up (even though I generated the form through
code)

So, fine. If you have a sub that you're going to call on 300
controls, declare it as a function -- I am not arguing against that
at all.

I'm arguing against declaring all user-defined subroutines as
functions, whether or not there is even the remotest possibility
that it will be used as a function someday. How hard is it to change
a sub to a function? All you do is change Public Sub to Public
Function -- no further changes in code are needed.

I just think it's deceptive to define as a function a piece of code
that doesn't return a value just because you want to avoid typing
the word "function" in place of "sub" at the point that 1 of those
subroutines should get used as an event argument in a
form/report/control.

It's particularly bad coding if you don't declare a return type nor
set the return value. This is the kind of thing that can badly
confuse a different programmer coming to the code sometime later, as
it implies "this is a piece of code that returns a value" but it
never does (except the default Null). You're writing code that
implies something about its use and then *not* using it that way.

I consider kind of practice to be a premature optimization. That is,
you're writing your code for an eventuality that will occur only
very seldom. Now, of course, if you write sloppy code where your
functions don't doesn't declare a return type and doesn't set a
return value, then it's easy.

But that's BAD CODE.

To get the benefit of Allen's recommendation, you have to write BAD
CODE.

And I just won't do that, nor will I stand by in silence while
someone recommends doing it.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

.

Relevant Pages

  • Re: Function versus Procedure
    ... a Sub is procedure that cannot return a value. ... it doesn't declare a return type, ... I've got forms with 300 controls on them where each control calls ... You're writing code that ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Change textbox/combobox colors with a procedure
    ... The Form's Current event procedure title is: Private Sub Form_Current ... Private Sub FormatControl(CTRL As Control) ... know how or what to declare in the global procedure or the ... Can a global procedure be called for a named control, ...
    (microsoft.public.access.formscoding)
  • Re: Change textbox/combobox colors with a procedure
    ... Private Sub subCondFormatting ... Private Sub FormatControl(ctrl as control) ... know how or what to declare in the global procedure or the ... Can a global procedure be called for a named control, ...
    (microsoft.public.access.formscoding)
  • Re: listbox click - nothing happens?
    ... The button would be the same...it's a VB.Net thing, not a specific control ... They'll already have the WithEvents on them, ... End Sub ... >>keyword and declare your sub something like ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Simple Insert Into...
    ... You can store unbound control data in a variable, ... in the sql. ... Dim strSQL As String ... In your form's Sub, you'll wind up with something like the following: ...
    (microsoft.public.access.modulesdaovba)
Quantcast