I came across this pdf Visual Basic™ 32-bit Application Development
Standards and Guidelines
and thought it might be useful for newbies (and maybe even some more experienced people)
It's not stricly a "code it better make it more efficient" but it will help people adopt best practice for writing their code.
6.2.1 Keep It Short
In general, routines should not be longer than one screen page. Routines longer than one screen should be broken down into subroutines.
I was not implying that one should use GOTOs or GOSUBs at all. In fact I never use them.
I don't think that if you are using VB you have to be all that worried about sacrificing such small speed/resources in order to code in a way that is human-freindly.
IMHO, if you are that freaked out about wasting speed/resources you might consider moving development to C++.
I do not go overboard with Functions/Subs either though. I like to stick to the above rule to keep every Function/Sub to about a screen-length, but it never happens ALL the time.
For example, I wrote a reporting tool in VB that took 40 hours to run from start to finish. I re-arranged alot of logic to account for the true speed/resource hog (which was my Excel object) and cut my time down to 20 minutes.
Could I cut it down further by using GOSUBs? I don't know I spose I could knock off another minute or 2 but what's the frigging point? Catch my drift?
I dont agree with many of the points layed out in this standards doc. But that does not really matter...
The thing that makes it good is that it is a standard which, if followed exactly, will result in easy reading/easy maintainable code.
I think it should be up to the project lead to stipulate what standard the application will be developed against. And then, all should follow those standards for the project.