how long are your procedures?

guys,

i think one question i've been thinking about for quite awhile but somehow never materialised in my head to ask is - how long are your procedures?

this seems to be a big party question again! woo hoo!! and EVERYONE is welcome!! (we'll keep this open so that anyone delayed by sun spot activity, extraterrestrial aberrations and wardrobe malfunctions won't miss out ok? haha = ))) !!! )

for me, cause i'm using vbWatchDog and it basically has try catch finally blocks AND MOST IMPORTANTLY!!! --> it has an unwind - which lets me get out of any procedure stack with 1 line of code (exits the stack by running the Finally block of the stack's top procedure then popping it off and going to the one below it until there are none left),

i love to use really short procedures. like maybe 20 lines? 40 lines? something like that - but my main concept is:

each procedure is a sentence.

then there are the paragraph procedures which are just all the sentence procedures in order.

then section procedures which are just all the paragraph procedures in order.

so as you can see i have a leaning tower of pisa haha - JUST THAT! hopefuly it doesn't lean cause i've got vbWatchDog already!! --> ok let's just assume it doesn't lean for this discussion ok? so far in all my crazy haphazard but hopefully still with very strict strcuture development, it HASN'T leaned yet! kudos to Wayne Phillips for that! = ))

so as you can see as well, i do a LOT of refactoring. not just for reuseability sake, but simply for me to read my code better. i admitted do have superbly long procedures as well - BUT that's only because i don't have the time to chop chop chop it into sliced pork chop!! haha = )) (caveat some procedures belong all together so i leave them together = ))  )

so for me refactoring is done for two things:
1) reuseability
2) readability

and i DO use comments for really stupid / silly things like even 1 liner codes - why? cause firstly, the green colour coding switches my mind into a different planar mode - ok i'm just reading the green things now. secondly it's in human language so i'm only using my human language compiler not my VBA semantics compiler = ) BUT --> then again at best i only have 1/16th the intellectual power yall have SO! this suits me haha = PP

do yall use long procedures guys? = ))
developingprogrammerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

GrahamSkanRetiredCommented:
Not sure that I understand the precise question, but I do agree that short procedures are desirable. My target (rarely achieved) is that the whole of the procedure should be viewable, without scrolling, in the editor.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Whatever it takes :-)

mx
0
Martin LissOlder than dirtCommented:
I would not go to any great pains to break up a block of code just because it was "too long" but I almost always pull out repeating code in the block and replace it with a Sub or Function and on occasions if there's a complex section  I will also replace it with a Sub or Function.

And as for the whole of the procedure being visible I have to ask on what monitor?  I code on a 27" MAC and I can fit a lot of code in the viewing area:)
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Mark WillsTopic AdvisorCommented:
Short and sweet whenever possible.

Call other procedures if needed.

Having said that (as a goal) I have had a few routines that do get quite involved and whilst I might have been able to go back and make it cleaner / more structured / more object oriented, I haven't because "it works" and if it aint broke.....
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
I lile MX's commnt "what ever it takes".

Most are short; maybe 25-50 lines.  But I've got some that run hundreds of lines.

As long as the procedure remains focused on the what the procedure was intended for (ie. importing an order), then I don't worry about the length.  The only time I break something out is if I'm doing the same thing more then once.

Jim.
0
Dale FyeCommented:
Like most of the others, I try to keep them short (viewable on a single 19" monitor page) but I don't break up procedures into little pieces to achieve this, unless it makes sense.

For me, what is more important than keeping each procedure short, is documenting it.  My code generally has about 1 line of remarks for every 4-5 lines of code.  I have so many projects to either maintain or under construction that without good explanations of what the code is supposed to be doing, I'd be lost.  This really helps the guy/gal that is following behind you and having to maintain your code as well.  They might not like the way you chose to do something, but if you explain it well, at least they will understand what you did and why.
0
aikimarkCommented:
* A rotatable monitor can also help the readability of routines, by switching into portrait mode.
* The only hard and fast rule on size is the character limit (64k per module or routine).
* As far as packaging the code, I try to use objects that have methods to perform specific tasks.
* I tell my programming students "Every time you copy/paste a block of code, you should think about making that block a routine (sub or function)."
* The name of the routine should completely describe its actions.  I normally restrict comments to alerting the next programmer to why some statements exist -- usually exceptional/bad data handling.
0
developingprogrammerAuthor Commented:
thanks guys! really appreciate yall sharing your practices on this!! = ))

fyed i really like your comment on how you have 1 line of comment for every 4-5 lines of code. i think this is something very important that i should adopt as well. it's very important to help us not to be lost.

aikimark thanks for your sharing! i thought you mentioned probably the most vital thing which is the character limit of 64k per module or routine! i didn't know that previously!! and yes, i also love to package things in objects ha, but i guess i have to be a bit smarter in terms of when i create objects - basically having a framework paradigm to guide my object creation = )

to everyone else, thanks so much for your sharing as well! definitely having so many experts share your opinions helped me to form a basis of what direction i should head towards in terms of procedure length! = )) thanks so much guys once again!! = ))
0
Martin LissOlder than dirtCommented:
You're welcome and I'm glad I was able to help.

Marty - MVP 2009 to 2013
0
developingprogrammerAuthor Commented:
Thanks Marty!! = ))
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"I lile MX's commnt "what ever it takes"."
And believe me, I wasn't being a smart ass in saying this either. I literally meant that. I have some self contained procedures that are quite long, which may or may not have 'outside' calls.

I have to say I'm a bit mystified at the nothing of aiming to keep the procedure within the 'viewable' area of a given monitor.  Cannot imaging putting that restricting on myself.

mx
0
Nick67Commented:

each procedure is a sentence.
then there are the paragraph procedures which are just all the sentence procedures in order.
then section procedures which are just all the paragraph procedures in order.
That description fills me with misgivings.  If you get hit by a bus, the person coming behind you may not be so happy.

A procedure is a logical group of actions that occur together to enact a desired result
A function is the code required to take any required inputs and return a desired value.

so as you can see as well, i do a LOT of refactoring. not just for reuseability sake, but simply for me to read my code better
That fills me with misgivings, too.  Refactoring working code is an opportunity to introduce bugs.  Refactoring code before it enters production is usually indicative that the logical sequence of results wasn't thought out before hitting the keyboard.  I refactor code when, as my military inlaws say, OOBE -- operation overtaken by events.  The time to split a procedure up is when you begin to have difficulty following the logic of the group of actions you have assembled.  SELECT CASE is nice, and nested SELECT CASE works well too, but if each case starts to be 60-80 lines, it gets hard to keep the logic straight.  Time to break the procedure up.

Because my stuff is used in-house, I put little or no error handling in.  An error is MY failure to plan for a contingency or situation in production.  I need my code to barf hard and badly, so the end users have to confront me about the problem and get it fixed.

So a procedure, in practice, is a block of code that, should it produce an error, will not affect any procedure but itself.  Cascading errors are real horrors to trace.  Errors when the code completes without error but does not always produce the desired result are even worse.  If my code barfs or fails to produce the desired result , it is because something in a particular procedure is wrong, not because an error in a call of a call of a call was 'successfully' handled and the code continued down to the point where it barfed.

YMMV
0
developingprogrammerAuthor Commented:
whao thanks Nick for your response!

A procedure is a logical group of actions that occur together to enact a desired result
A function is the code required to take any required inputs and return a desired value.

yup you expressed it perfectly. this is what i generally do as well but i didn't express it as well as you. however, i combine this with what you said next

The time to split a procedure up is when you begin to have difficulty following the logic of the group of actions you have assembled.  SELECT CASE is nice, and nested SELECT CASE works well too, but if each case starts to be 60-80 lines, it gets hard to keep the logic straight.  Time to break the procedure up.

so i try and group things logically and reuseably as well, but when it becomes too long i refactor it.

hrmm Nick but come to think of it, after reading your really really good comment, i think i may just group procedures based on logical groupings.

hrmm.. but ya if it's too long it's a problem too. but how do i show that this refactored procedure's logical group is linked to its parent procedure logical group as well? so one logical group contains multiple procedures. hrmm, not really right cause we're using the procedure as a sign of grouping.

hrmm may be i should just stick with really long procedures so long as it's in the same logical group and it's not being used by different procedures. just have very good comments and really neat code.
0
Nick67Commented:
stick with really long procedures so long as it's in the same logical group

Following the logic of a lineal progression of actions, no matter how long, isn't that tough.
This happens...then that..next this...then on to that...and so on.
And if there is no subset of those actions that happen in the same order, for the same reason, to produce the same result, then there isn't any reason for anything but a single, long procedure.  Start to introduce IF...THEN...ELSEIF or SELECT CASE, and you start skipping blocks of code in following the logical progression of the procedure.  When the sequence of possibilities means that half or more of the code in the procedure isn't utilized in producing the desired result (because it is in the cases or elses not valid for a given possibility), it is time to think about splitting things up.

Select Case x
        Case 1
             '80 lines of code
        Case 2
              '4 lines of code
        Case 3
              '25 lines of code
        Case 4
              '10 lines of code
End Select

Open in new window


is probably much better as

Select Case x
        Case 1
             Call MyProcedureWhenXisOne
        Case 2
              '4 lines of code
        Case 3
              Call MyProcedureWhenXisThree
        Case 4
              '10 lines of code
End Select

Open in new window


You can follow the logic of the select case in the procedure it is in, and for the complex details, refer out to the called subs.  Making Cases 2 and 4 into subs would probably detract from readability and maintainability.  They are short enough to see inline, so there is not enough to be gained to make up for the loss associated with switching away to view their logic.  When grasping this code, you'd look at the called procedures first to get a rough idea of what they do, and then come back and review the whole nine yards -- but you can only load and keep so much straight in your head.  Knocking all four into subs starts to push that limit.  Don't do so frivolously, or as a matter of style.  Do it because there is enough code there to make the mental effort worthwhile.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
developingprogrammerAuthor Commented:
whao whao whao whao whao Nick!! your 2 posts really formed the framework as to how i'm going to approach refactoring, splitting code and grouping them!! and your use of MYPROCEDUREwhenxisone MYPROCEDUREwhenxisthree is really really good!!!!!! you know for so long i've been learning all these refactoring techniques but no real framework to approach how i slice and dice my code. your 2 posts really solidified my ideas and gave me a really concrete approach Nick!! = ))

hrmm Nick how about classes - when do you create classes and when do you do class level refactoring? for me, i do understand very clearly that VBA is object based not object oriented, but i try as much to implement OOP and its principles - simply cause it's a time tested methodology of organising things.

i use interfaces a lot and also some advanced techniques of interfaces where they refer to themselves so as to put the standard code in the interface themselves. these advanced technique are of course not discovered by me (my name being developingprogrammer haha = PP ) but rather taught by Bitsqueezer / Christian whose article was published in the newletter = ))

i also use some design patterns e.g. singletons, some form of factory patterns etc. everything is quite scaled down cause it's VBA but i try to incorporate these advanced concepts 1) for practice, 2) for scalability. i do understand that sometimes keeping it simple-stupid is better, but if the extra effort helps me learn as a developing programmer, why not?

if you could share some of your class creating strategies that would be great Nick!! very interested to hear them!! = ))
0
Nick67Commented:
about classes - when do you create classes and when do you do class level refactoring

That sir, might be another question you wish to ask and get a wide sampling of opinion.

For me, in Access, I don't use classes--mainly because until I took some .NET training I didn't really grasp what the point would be.

If I were to refactor things -- I won't because everything works just fine and I don't need to introduce new bugs -- I could use a class to deal with a LOT of my recordset setup work.  There's a hell of a lot of

Dim db as database
dim rs as recordset
set db = currentdb
set rs = db.openrecordset("some sql",dbopendynaset, dbseechanges)
rs.movelast
rs.movefirst

if rs.recordcount = some value then
    'some actions
end if

Open in new window


To have built a class to do all that and invoke instances of it, in hindsight, would have been convenient.
0
developingprogrammerAuthor Commented:
i see Nick, the recordset setup class is a fantastic idea!! i want to implement that in my project in the next iteration = )) thanks so much for all your sharing!! am reopening the question to include your solution as part of the answers!! = ))
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"class level refactoring"

Wow ... a new term!
0
developingprogrammerAuthor Commented:
0
Nick67Commented:
Don't re-open it.
Points aren't really that important
0
developingprogrammerAuthor Commented:
ok thanks Nick but i would like to flag your comment as best solution because whilst the other experts solutions are super fantastic as well, your guidance on how refactoring is linked to logical grouping and how to name child procedures, that was what i was looking for = )
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"how long are your procedures"
Sub Questions:
  " how long is this question?"
  " how long are the posts?"
lol
0
Nick67Commented:
how to name child procedures
Maybe it should be a given, but in naming ANYTHING, I look to give it the shortest meaningful name that I can -- but that, too is a whole different question.  A procedure's name should capture the gist of what it does.  If it exists primarily to be called by other procedures, a comment right of the nose saying
'Called by SomeControl_Click() when SomeSetOfActions are required

Open in new window

is good practice, too.

If your procedure has optional and/or mandatory arguments, comments that explain their purpose can also be helpful.

Your naming convention and your comments exist to help others -- or yourself, if enough time and events have passed -- grasp just what the heck you are attempting to accomplish.

In as few words as needful.

And 'needful' is a VERY subjective word!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.