Calling a function as if it is a subroutine

[Chrissirhc]

I noticed today that I can call a function as follows:

myFunction a, b

rather than

result = myFunction (a,b)

I used the first line because in this case I didn't really care what the return result was. In fact the function used to be a sub until I changed it today to meet some new requirement.

Is using the above 1st line ok?

Thanks in advance,

Chris

 

[SkipVought]

Sure.

Somtimes what you might consider doing is returning a completion code, to indicate that the function ran to completion or encountered a definable error condition. Then the calling routine can deal with that conditon.

Skip,

_[red][/red]

 

[Chrissirhc]

That is exactly why I turned the subroutine into a function. However, sometimes I don't care how it went and it looks like in that case I can just call the function as a subroutine. That doesn't feel right, but saves me having to rewrite code. I wanted to know if that was generally bad practice and unconventional.

 

[Chrissirhc]

Any gurus have any thoughts on this?

Thanks,

Chris

 

[fumei]

Well I have to wonder why you would have ANY instruction (either Function or Sub) where you don't care how it went. If you don't care, then why even run it? If it does not matter whether it worked properly (or not), then why not simply not run it? As Skip mentions errors - what if there IS an error?

In any case, generally functions are used to return a single value. They don't have to, but generally that is what they are used for. Functions of course can, and do, have multiple instructions. But they are generally used to return a single value.

Subs are simply chunks of instructions.

So:

myFunction a, b

really is acting somewhat as a Sub. I am not sure why you would change it to a function. If it is a chunk of instructions - taking parameters "a" and "b" and doing something with them - and you don't care about getting any return value, then really it is a sub.

In practical terms....it doesn't matter. If a function does not have an explicitly defined value to return, it will do the instructions within the function anyway. For example:

Function DoThis()
Selection.HomeKey Unit:=wdStory
Selection.EndKey Unit:=wdStory
End Function

Sub testFunction()
MsgBox DoThis
End Sub

If you run the Sub testFunction you will get a blank messagebox - as there is no VALUE for DoThis. The instructions within DoThis will be carried out - the Selection will be moved to the start of the document, then moved to the end of the document.

In the above, again, general practice would have those instructions as a Sub, not a Function.

Function DoThis() As String
Selection.HomeKey Unit:=wdStory
Selection.EndKey Unit:=wdStory
DoThis = "Selection is now at the end of the document."
End Function

Sub testFunction()
MsgBox DoThis
End Sub

Running the Sub testFunction would display a messagebox with the VALUE of the function (defined as a String).

Another example:

Function DoThis() As Long
Selection.GoTo What:=wdGoToTable, _
     Which:=wdGoToFirst, Count:=3, Name:=""
DoThis = Selection.Range.Start
End Function

Sub testFunction()
MsgBox DoThis
End Sub

In this case, running the Sub testFunction will action the instructions of the Function (move the Selection to the start of the third table in the document), and display the VALUE of the returned function. In this case the numeric location of the Selection point - ie. the location, as Long, of the first charcter, in cell (1,1) of the third table in the document.

There is nothing wrong with having a function with no explicit return value. IMHO though...you may as well use a Sub. The purpose of functions, again IMHO, is in fact to return a value. Subs, in themselves, do NOT return a value. Of course they can be used to SET a value.

Functions on the other hand are/were designed specifically to return a value.

Bottom line? There is nothing wrong with using:

myFunction a,b

I, however, prefer to use Subs as chunks of instructions, and Functions as chunks of instructions that tell me something afterwords.


Gerry
My paintings and sculpture

 

[fumei]

And before anyone makes the comment...yes, there should be error trapping within the function example on going to Table 3. That is, you should check to see if if there IS a Table 3 first.

Gerry
My paintings and sculpture

 

[fumei]

Just to continue my rant....what else is new...

Function CellContents(TableNum As Integer, _
CellRow As Integer, _
CellCol As Integer) As String
CellContents = ActiveDocument.Tables(TableNum). _
   Cell(CellRow, CellCol).Range.Text
End Function

Sub GetCellContents1()
MsgBox CellContents(2, 3, 3)
End Sub

The Sub GetCellContents1 uses the function to get a return (string) value of the Cell(3, 3) in Table 2 and display it. The power of using a function for this is that the function returns what you want - the string contents of the cell. The FUNCTION has the variables. The SUB passes those variables.

To do the same thing using only Subs would be:

Sub GetCellContents3(TableNum As Integer, _
CellRow As Integer, _
CellCol As Integer)
Msgbox ActiveDocument.Tables(TableNum). _
   Cell(CellRow, CellCol).Range.Text
End Sub

Sub CellContents2()
Call GetCellContents3(2, 3, 3)
End Sub

Ok? They both do the same thing. Display the contents of the cell.

The difference though is this. The Sub hard codes the messagebox. Rather, it hard codes the result within the scope of the Sub.

The Function (which returns what you want - the string), can be used anywhere within the scope of the module.

The Sub only returns what you want within the scope of the Sub. Unless, of course, you make a global variable. Which may be what you want, but it does add an extra variable.

Gerry
My paintings and sculpture

 

[Chrissirhc]

Thanks for your thoughts Gerry.

I'm actually using the solution I have because there is a situation where I really do care what the result is like. But most of the time I don't. So, I guess when I care I will be using it as a function and when I don't care I'll be calling it as a subroutine. I just wondered whether Excel VBA professionals would look at the code and say this is confusing or this is really bad practice...

 

[fumei]

1. Whether it is confusing, or bad practice, has nothing to do with it being Excel, or any other VBA application.

2. Hopefully, you have the answer....No, it is not.

However, I am not sure you really caught what I was saying.

So, I guess when I care I will be using it as a function and when I don't care I'll be calling it as a subroutine.

That is NOT the point....at all.

It is not about caring what the result is.

But...shrug....whatever...

Gerry
My paintings and sculpture