Comments on: Code Construction

By: Dick Kusleika

Dick Kusleika — Fri, 13 Mar 2009 14:34:00 +0000

Good point Jon. I lose nothing by writing it as a function and just calling it as a sub.

Bob: Yes, DDoE Tools. I've often thought of that. I use about five things from MZ-Tools and a few of them to almost what I want. Those five things are important, mind you, but there's a lot in MZ that I simply don't use. So I wouldn't have to replicate everything in MZ for my purposes. I really hate programming in the VBE though - too much text manipulation.

By: Ross

Ross — Fri, 13 Mar 2009 10:02:00 +0000

@ Jon and Bob,
Sounds like you guys would get on well with F#? It did strike me when I was reading about F#, that well, you could just write all you code as functions in any(most) languages, so why have one that only (not only anyway!) uses functions.

Now I'm 100% sure that I have totally missed the point, but as I have always said ignorance is no reason for not forming a opinion!

As always interesting reading, good work Dick! Nice ideas Jon Bob and Alex.

By: Jon Peltier

Jon Peltier — Fri, 13 Mar 2009 02:28:00 +0000

Dick -

Like Bob, I tend to make my procedures into functions. If I don't need the result, I can still call it as a sub and ignore the return value. But somewhere else in the project I may decide I want that return.

Like you said, it depends.

By: Bob Phillips

Bob Phillips — Thu, 12 Mar 2009 23:41:00 +0000

On your property code thing, I don't agree with that, but your style is your style. I am a real pedant, I type my properties from scratch every time. The one that always gets me is a Property Let that takes a parameter, catches me every time.

Anyway, back to my point. If MZ-Tools won't format as you want, write a simple VBE procedure yourself and assign it to a toolbar button, DDoE-Tools!

By: Bob Phillips

Bob Phillips — Thu, 12 Mar 2009 23:34:00 +0000

Dick,

Seeing as you are listening to me at last, I only use functions, never subs. I was persuaded that every procedure should return a result, even if it is only to signify success or failure. I took the principle on board, but I admit that I prefer my return indicator to a Byref (and last) argument, probably a throwback to use of API calls.

By: Dick Kusleika

Dick Kusleika — Thu, 12 Mar 2009 16:10:00 +0000

Scott: Good question. I suppose I should.

Jon: I use PED error handling. But for a procedure surrounded by an On Error Resume Next, it didn't seem necessary to return anything. There are some situations where I use On Error Resume Next, that it would make sense to return something, like

Set wb = GetWorkbook(sWorkbookName)
If Not wb Is Nothing Then

rather than

On Error Resume Next
Set wb = Workbooks(sWorkbookName)
On Error Goto 0
If Not wb Is Nothing

But for the collection example, I don't care what happened.

By: AlexJ

AlexJ — Thu, 12 Mar 2009 15:08:00 +0000

Per Jon's comment, I've started using Functions with sting returns. The strings are public variables named like xErrOK (="OK"), xErr1 = "Error Type 1?, etc. If I hit an error in the function, I return that value to the caller which invokes an error process with messages, etc. (I like to use If Function1 = xErr1 then Err.Raise(1001) - or something like that.)

Not in the same class as the approach used in "Professional Excel Development", but works for me. I can provide clearer explanation if anyone wants.

By: Jon Peltier

Jon Peltier — Thu, 12 Mar 2009 14:28:00 +0000

Change

Public Sub AddToColl(blah blah)

into a function so you can return a boolean to indicate success or a long (i.e., a user defined type) to indicate something useful about what happened within the procedure (the type of error, the type of data, or whatever).

By: Scott

Scott — Thu, 12 Mar 2009 12:48:00 +0000

So, as you start to change your coding techniques, are you going to change your VBA Framework application to match…?

By: Petr Santarius

Petr Santarius — Thu, 12 Mar 2009 07:09:00 +0000

To make your code compact but readable you can write it like this (add spaces):

Public Property Get Path() As String: Path = msPath: End Property

Public Property Let Path(ByVal sPath As String): msPath = sPath: End Property

The same works with Dim and Const statements

Dim intSize As Integer

Dim dblBigBoss As String

Petr