Advice please on good practice (1 Viewer)

[smiler44]

Is it better to put all the code in one sub routine or use a call statement to run other sub routines?
I am concerned that putting all the code in one sub routine with lots of if and end if can become difficult to read and follow.

If it is better to use different sub routines, do I put all these sub routines in one module or use a number of different modules?

thanks

smiler44

 

[MajP]

A lot of this is subjective and deals with readability, maintainability, ease of use, and ability to debug. You can go to either extreme.
I tend to have a lot of modules if they are a related group of methods (printUtilities, applicationUtilities, FormUtilities, ImageUtilities etc...)
But I do not just add extra modules based on size

I tend to have lots of very short procedures and functions because that is readable to me. Other people tend to like to see everything in one place.
So it is an art more than a science.
I can look at code and know it when it is bad and hard to read. But different people can organize differently and get clear code. The way my mind thinks makes sense with many modules and small procedures that do one thing.

 

[Gasman]

I myself would have one routine per task.
Then if I needed to run 3 out of 5 tasks, I would call the 3 routines.

 

[The_Doc_Man]

The general rule in ANY part of programming, whether we are talking databases, complex web sites, or some utility program, is "Divide and Conquer." There is a point where dividing up a subroutine goes too far, but from a pragmatist's point of view, "putting all the eggs in one basket" isn't such a good idea either.

A question you must ask is "can I use some part of this routine in more than one context?" Code-reuse is always a good thing if it is possible.

Some folks have a rule of thumb that says, if my routine's code won't fit on one screen, I have to split it into page-sized units. Other folks put limits like "no more than 100 lines". These are all self-imposed standards, or perhaps simply guidelines. You do what you have to do - but look for cases where you can isolate some routine to a very simple sequence, because that makes debugging easier when you can isolate code parts to become separate routines. Ease of debugging is NOT a trivial reason to split code into distinct parts.

As to "call statements" - VBA doesn't actually require a formal CALL statement, and if you DO use one, you have to remember parentheses. But from a syntax viewpoint, the following two statements are identical:

CALL MySub( x, y, z )
Mysub x, y, z

 

[RonPaii]

Each subroutine should do one thing. If you find yourself doing "exit sub" or deep" if then elseif", it's time to break it up. It also simplifies your error trapping with fewer errors to handle per routine.

 

[tvanstiphout]

If you have a DoEverything procedure, you probably also have procedure arguments that drive how the proc runs. E.g.
public sub DoEverything(arg1 as string, arg2 as long)
if arg1 = "A" then
'Code to do Thing1 goes here.
elseif arg1 = "B" and arg2=99 then
'Code to do Thing2 goes here

This is a clear example of where breaking things up would be beneficial for readability and testing and maintenance.
Note that even if you don't have arguments, getting these "driver variables" at the top of the proc is equivalent.

 

[smiler44]

Thank you all for the advice. I think I will add a couple of new modules, so that the main macro does not get diluted with code and I lose track of what code is proper to the task in hand.

thanks again
smiler44