I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

I said I was OLD, couldn't remember the word "module" to save my life. Not
ignorance, just a little "Halfzheimer's" <g). Non "Process" est, sed
"Module". Mea culpa <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

There is a limit of about 64K on the size of a module. You would export it
to a .bas file, then look at the size of the file. The limit is not
published anywhere, but appears to be a practical limit - above that you
start having problems. Beyond that, I don't believe there is any limit.
Some people create huge procedures using the macro recorder.

Use of subroutines is encouraged from a maintenance/readability standpoint.

--
Regards,
Tom Ogilvy



"Dave Birley" wrote:

I said I was OLD, couldn't remember the word "module" to save my life. Not
ignorance, just a little "Halfzheimer's" <g). Non "Process" est, sed
"Module". Mea culpa <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

Use good programming practives. Usually around 200 - 250 line of code per
module is the limit. Better than the 500 punch cards I had to use in
college. Consider how you are going to tet the code in making the decision
to have one or multiple modules.

You didn't say if you where building a subroutine or a function, but it is
always good to create sub-functions where possible.

"Dave Birley" wrote:

I said I was OLD, couldn't remember the word "module" to save my life. Not
ignorance, just a little "Halfzheimer's" <g). Non "Process" est, sed
"Module". Mea culpa <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

Ok, so to use sub-modules (and I really like that idea), suppose I have this
construct:

Dim blnYunky as Boolean
Dim myParameter as Long
For Each Yadda In Yading To Yadong
If Bingo Then
'what do I put here to call module Fooby with a parameter?
blnYunky = MyModule(myParameter, myResult) '??
Endif

Private Function MyModule (ByRef myParameter As Long, _
myResult As Boolean) As Long
For Each rngWiggy In Range(rngBugfree(1), rngBugFree(myParameter)
'Yadda, yadda
If MySomething Then
MyResult = True
End If
Next rngWiggy
End Function

Is that the sort of thing you mean?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Joel" wrote:

Use good programming practives. Usually around 200 - 250 line of code per
module is the limit. Better than the 500 punch cards I had to use in
college. Consider how you are going to tet the code in making the decision
to have one or multiple modules.

You didn't say if you where building a subroutine or a function, but it is
always good to create sub-functions where possible.

"Dave Birley" wrote:

I said I was OLD, couldn't remember the word "module" to save my life. Not
ignorance, just a little "Halfzheimer's" <g). Non "Process" est, sed
"Module". Mea culpa <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

Yes, except MyModule doesn't return anything.

"Dave Birley" wrote:

Ok, so to use sub-modules (and I really like that idea), suppose I have this
construct:

Dim blnYunky as Boolean
Dim myParameter as Long
For Each Yadda In Yading To Yadong
If Bingo Then
'what do I put here to call module Fooby with a parameter?
blnYunky = MyModule(myParameter, myResult) '??
Endif

Private Function MyModule (ByRef myParameter As Long, _
myResult As Boolean) As Long
For Each rngWiggy In Range(rngBugfree(1), rngBugFree(myParameter)
'Yadda, yadda
If MySomething Then
MyResult = True
End If
Next rngWiggy
End Function

Is that the sort of thing you mean?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Joel" wrote:

Use good programming practives. Usually around 200 - 250 line of code per
module is the limit. Better than the 500 punch cards I had to use in
college. Consider how you are going to tet the code in making the decision
to have one or multiple modules.

You didn't say if you where building a subroutine or a function, but it is
always good to create sub-functions where possible.

"Dave Birley" wrote:

I said I was OLD, couldn't remember the word "module" to save my life. Not
ignorance, just a little "Halfzheimer's" <g). Non "Process" est, sed
"Module". Mea culpa <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Ok, so to use sub-modules (and I really like that idea), suppose I have this
construct:

Dim blnYunky as Boolean
Dim myParameter as Long
For Each Yadda In Yading To Yadong
If Bingo Then
'what do I put here to call module Fooby with a parameter?
blnYunky = MyModule(myParameter, myResult) '??
Endif

Private Function MyModule (ByRef myParameter As Long, _
myResult As Boolean) As Long
For Each rngWiggy In Range(rngBugfree(1), rngBugFree(myParameter)
'Yadda, yadda
If MySomething Then
MyResult = True
End If
Next rngWiggy
End Function

Is that the sort of thing you mean?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Joel" wrote:

Use good programming practives. Usually around 200 - 250 line of code per
module is the limit. Better than the 500 punch cards I had to use in
college. Consider how you are going to tet the code in making the decision
to have one or multiple modules.

You didn't say if you where building a subroutine or a function, but it is
always good to create sub-functions where possible.

"Dave Birley" wrote:

I said I was OLD, couldn't remember the word "module" to save my life. Not
ignorance, just a little "Halfzheimer's" <g). Non "Process" est, sed
"Module". Mea culpa <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Ok, so to use sub-modules (and I really like that idea), suppose I have this
construct:

Dim blnYunky as Boolean
Dim myParameter as Long
For Each Yadda In Yading To Yadong
If Bingo Then
'what do I put here to call module Fooby with a parameter?
blnYunky = MyModule(myParameter, myResult) '??
Endif

Private Function MyModule (ByRef myParameter As Long, _
myResult As Boolean) As Long
For Each rngWiggy In Range(rngBugfree(1), rngBugFree(myParameter)
'Yadda, yadda
If MySomething Then
MyResult = True
End If
Next rngWiggy
End Function

Is that the sort of thing you mean?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Joel" wrote:

Use good programming practives. Usually around 200 - 250 line of code per
module is the limit. Better than the 500 punch cards I had to use in
college. Consider how you are going to tet the code in making the decision
to have one or multiple modules.

You didn't say if you where building a subroutine or a function, but it is
always good to create sub-functions where possible.

"Dave Birley" wrote:

I said I was OLD, couldn't remember the word "module" to save my life. Not
ignorance, just a little "Halfzheimer's" <g). Non "Process" est, sed
"Module". Mea culpa <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

Here is a sample of how modular code can work in VBA. The first one is the
control
sub which calls the others in the order they need to run. The sub routines
are listed in order but they don't have to be. They can be anywhere in the
standard module.

Sub addErase()
addCellValue
moveCellVaule
changeCellValue
delCellValue
End SuB

Sub addCellValue()
Range("A1") = "Hello"
End Sub

Sub moveCellValue()
Range("A1").Value.Cut Range("B1")
Application.CutCopyMode = False
End Sub

Sub changeCellValue()
Range("B1").Value = Range("B1").Value & "World"
End Sub

Sub delCellValue()
Range("B1").Clear
ThisWorkbook.Save
ThisWorkbook.Close
End Sub


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC

Thank you (and everyone) for all the help on this. As I am primarily a
"practical" (vs. "theoretical") learner, the example you gave was a huge
help. I really appreciate everyone's patience with me <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"JLGWhiz" wrote:

Here is a sample of how modular code can work in VBA. The first one is the
control
sub which calls the others in the order they need to run. The sub routines
are listed in order but they don't have to be. They can be anywhere in the
standard module.

Sub addErase()
addCellValue
moveCellVaule
changeCellValue
delCellValue
End SuB

Sub addCellValue()
Range("A1") = "Hello"
End Sub

Sub moveCellValue()
Range("A1").Value.Cut Range("B1")
Application.CutCopyMode = False
End Sub

Sub changeCellValue()
Range("B1").Value = Range("B1").Value & "World"
End Sub

Sub delCellValue()
Range("B1").Clear
ThisWorkbook.Save
ThisWorkbook.Close
End Sub


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC