Printable View
I'm redesigning an app of mine and I am trying to as best job of coding as possible. I was just wondering what you guys think are some very good practices in stable programming for VB. I already use Option Explicit and many On Error statements, but is there anything else you can to do to increase the overall stability of a vb program?
Make sure you have tight control over sub routines calling other sub routines. Subs running amok can cause all sorts of nasty issues.
set object to nothing when done with them is a good one
try to avoid loops within loops if possible.
When you say objects, do you mean forms or any type of object like a control. If its a control how to you unload or remove or Set nothing to a control. The only unloading I've used in my programming is
Unload Me upon program exit.
dim obj as Object 'declare object
set obj = New Object 'create instance
'you coding with object
set obj = nothing 'destroy instance
use some form of a nameing convention for your variables etc.
i.e.
intPeople (integer variable)
strName (string variable)
instead of just
People
Name
This way you know the type of variable just by looking at the name and your more likely to get it right :rolleyes:
oh yeh, and don't use variants unless you have to, they big and slow and take up way too much space (that reminds me, i forgot me dads birthday - bollix)
Also writing some "bulletproof" functions, such as:
Code:Public Sub SafeSetFocus(ByVal ctl As Control)
If ctl.Visible And ctl.Enabled Then
ctl.SetFocus
End If
End Sub
If you have the time, trace your code and make some kind of documentation.
Getting it visually, helps you spot design-flaws, redundant code etc.
Goes for all programming langs.
BIW
Two things that were drummed into me when I was doing
Assembler in DOS:
1. Every function/subroutine has 1 and only 1 exit point. There is
no reason to have an "exit sub" command anywhere except
where you finally exit after success/failure.
2. Goto should be avoided BUT it is absolutely preferable to
violating rule 1. Much of the aprobrium attached to GoTo was
caused by beginners in the spaghetti code programs they would
foist on the world about 30 years ago. Using a GoTo only
towards the final exit avoids almost all of the spaghetti. If you
use GoTo, Only go towards the exit point.
Trust me, nothing I've seen yet is as frustrating than attempting
to follow a programs progress with more than 1 exit point.
Personally, I disagree with that last statement.
I do agree you should keep use of exit sub/functions to a minimum.
Sometimes, however, I find it easier to read my own code if I do all the validation at the beginning of a sub or function, and exit if I need to before I actually do what the function/sub was designed to do.
Use comments for every statement that you thinkwill help you to remind in case you get out of touch...
I have to agree with commenting your code. It may sound stupid, but I just recently started working on a project I haven't touched in almost a year, and for the life of me, I can't figure out what's going on in some of my code.
So comments = good.
Validating before doing good.
But to skip the intervening code (sans an artificial if or
superfluous function call).
GoTo Xit_FunctionName
where Xit_FunctionName is just before End Function/End
Subroutine
Commenting is ESSENTIAL.
For the most part, more is better. Don't write books though.
I have been programming for 30+ years and agree with much of what others have said here and while it duplicates much of what has already been said here are some good rules to follow:
- Document, document, document. This includes annotating code changes with something like the following rather than just changing the line
Code:'*** Start Change #1 ***
' If strType = CRITICAL Then
If strType = WARNING Then
'*** End Change #1 ***
MsgBox "Some message"
End If
- Have written standards that contain naming conventions similar to the one mentioned above and mentioning that variable names should be meaningful rather than "x", "y" and "z" or "i".
- Every function should be specifically typed and should return a value.
- Avoid Public variables in favor of classes even if that class contains nothing more than a few Boolean properties.
- Rather than directly updating the properties of a form's controls, create Properties in the form and Get the property value when it is time to show the form. This avoids unexpected problems because direct updates to any visible property of a control in a form will immediately load that form, executing the form's load event which may well have other unexpected consequences.
- Always use Case statements instead of multi-level If-Then-Elses
- Trust your friends but check anyhow. In other words always validate input even if you are sure you know that it will always be OK.
- Buy and use a code analyzer
- Perhaps most importantly, develop and exercise a set of test cases for your program which will test all its functions. If possible have someone else do the testing.
Hi Marty
there's always gotta be some dissent :) ...
Avoid Public variables in favor of classes even if that class contains nothing more than a few Boolean properties.
There is nothing wrong with using pub vars if u keep them organized and to a minimum. updating a pub var is much much quicker than using a class.
Always use Case statements instead of multi-level If-Then-Elses
I agree with this for code organization.. but if the statements are in a time critical loop or such then go for the If Thens which again are much faster.
My firm belief is that you should start with an organised structure for your program... everything in its place. You will develop clean code, reusable code etc and never feel overwhelmed as your program grows.
And re comments... i think that it is best to describe (in normal words) what is going on in a sub rather than just commenting each line. It may be obvious to you now why variable X is updated from Y to Z but what is the point of it in the broader scheme of things...
Regards
Stuart
I didn't mean to suggest that you can't use them, but a Let/Get pair in a class is and way to "keep them organized" and as far as "quicker" if you are talking about the coding effort, once you have done it, coding a simple class is trivial, and if you are talking about program speed a Public var is certainly faster but unless you need to update the var or class many times in a row it really makes no difference.Quote:
There is nothing wrong with using pub vars if u keep them organized and to a minimum. updating a pub var is much much quicker than using a class.
Are you sure? It may well be true, but I was wondering if you have actually ever timed it.Quote:
but if the statements are in a time critical loop or such then go for the If Thens which again are much faster.
Yeah Marty .. there was a whole thread on this a month or so back... basically u could make an If then statement as messy as possible, nested to the nth degree and covered in shag pile carpet and it was still much quicker than a Select Case statement.Quote:
Originally posted by MartinLiss
Are you sure? It may well be true, but I was wondering if you have actually ever timed it.
MikeyCorn also started a thread where we compared With .. End With etc and a number of other things contained in a VB World article... some of the results were quite surprising
Regards
Stuart
I decided to test this.
Perhaps I am going about this wrong, please check.
But in the attached program, select statements are executing faster than if statements.
I am doing nothing in either, but I also am not breaking in the select statement for sake of making the program iterate through them all.
Still, selects are coming out faster.
Did I do something wrong?
P.S. make sure you use a large number, like 4 million.
Hi Lord Rat
I havent got time now but will check later on...
couple of things tho. can u modify ur code so that
a) use gettickcount api... much more accurate
b) dont call seperate functions that could skew results
c) dont use calcs such as mod (i know they are same for both but still could affect)
d) do add some feeble statements within the If Then's and Select case....
Another thing... I dont think u are actually testing what we are talking about. Your prog uses multiple if thens compared to a select case.. we were talking about nesting of If then statements in comparison to using select case. So u could either nest your example or use ElseIf instead of a new statement and do a more accurate calculation that way
Regards
Stuart
OK, stay tuned . . .
So, how do I use GetickCount?
One thing nobody has mentioned...
Design the software on paper before you write a line of code
Nobody (well, almost nobody) ever does this... I didn't do it for ages, then finally had the opportunity to, and I spent two weeks working throughthe design on paper. Initially, I had extimated the project taking about four months - so far it's been 3 weeks, and I've nearly completed it (in beta testing at the moment).
You would no believe the difference decent design can make...
- gaffa
Quote:
Originally posted by gaffa
One thing nobody has mentioned...
Design the software on paper before you write a line of code
Nobody (well, almost nobody) ever does this... I didn't do it for ages, then finally had the opportunity to, and I spent two weeks working throughthe design on paper. Initially, I had extimated the project taking about four months - so far it's been 3 weeks, and I've nearly completed it (in beta testing at the moment).
You would no believe the difference decent design can make...
- gaffa
And I thought I was the only one doing this!!!!!
bet Gaffa is almost as old as me then, because it seems to be the "Old Skool" way of doing things.
Gaffa, are you in your 30's ???
An EXCELLENT piece of advice which brings FANTASTIC rewards in speed and structure of coding, AND if you are sensible to keep it, it makes going back to an old project SO much easier!
Pigmy
:cool:
I'm not quite 30 (turned 27 a week ago), but I've got a computer science and software engineering degree, so the SDLC, use case modelling, CMM and the like were all drilled into me...
Unfortunately, I don't often have the luxury of time to do comprehensive design and documentation, which sucks, cos it eventually makes the project completely un-maintainable...
- gaffa
This is really a debugging practice, but if something isn't working out right and you're not getting an error with a subroutine, throw in a few message boxes. If the message box fires, you know that the code got to that part. This is an especially good idea if you use alot of IF statements.
Quote:
Originally posted by Lord_Rat
So, how do I use GetickCount?
VB Code:
Yeah and i even started a birthday thread for you but it was a pub hol weekend and so died in the arse :pQuote:
Originally posted by gaffa
I'm not quite 30 (turned 27 a week ago), but I've got a computer science and software engineering degree, so the SDLC, use case modelling, CMM and the like were all drilled into me...
so a belated happy birthday! :)
Yeah i design on paper and that was sort of what i was alluding to by mentioning a structured design... i even design the gui's on paper first and run it over quite a few times before putting on the computer... and for sure it cuts down time... i take about a month to complete proggies from go to whoa and then do the novelist thing of putting it away for a while and then looking at it with fresh eyes.
This is interesting @ PeterP + Gaffa.
What kind of methods do you use for putting things on paper.
I mean, for simple projects any kind of flowcharts will do I guess, but when it comes to larger projects they usually turn up insufficient.
Oh, and yes I too design software by starting with pen and paper.
Heck, I even write pseudo-code :)
BIW
A comment on Hobo's reply.
If you are able to, it is usually better taking advantage of VB's debugging features (breakpoints, step-by-step tracing etc).
Sometimes however you are not allowed to do that. At that point Hob's solution is a quite good one.
BIW
I know this is pretty basic, but I've seen people not do it.
After typing;
You should type:VB Code:
Then put the body of the If statement in.VB Code:
Same for Whiles and Fors
After opening a Connection and Recordset, Close them, then add the code to use them.
To increase code reusability use Standard Modules...I had a program in which I was to connect to SQL at every 3rd form...so instead of writing again n again...you could write it in a module and simply call it whenever needed...this prevents you writing the same code 10 times...
the way I do it is to start off with good old Systems Analysis.Quote:
Originally posted by biw
This is interesting @ PeterP + Gaffa.
What kind of methods do you use for putting things on paper.
I mean, for simple projects any kind of flowcharts will do I guess, but when it comes to larger projects they usually turn up insufficient.
Oh, and yes I too design software by starting with pen and paper.
Heck, I even write pseudo-code :)
BIW
What do you want the system to DO.
Write it down, it's amazing how much just doing this will throw up. This gives you a good starting point then for the following:
What INPUT is required from the operator.
What type of OUTPUT is required from the system.
I then try to draft the input screens (forms) and output (forms and printed matter)
Then I'll draft a flowchart of the program flow.
This can be VERY simple sometimes, and at times NOT!
Then I will get the flowchart and break it down further starting to turn it into Pseudo code.
This I will then start in the VB IDE using JUST remarks. It then becomes obvious what will need to go into modules etc.
Then i'll start turning the pseudo code into real code starting with the most often called functions and routines.
If you can get those working flawlessly, it makes everything else easy.
etc. etc. etc.
I could go on and on and on ........... and on .... and on
But hopefully this has given you an idea of how i'll plan.
If you are planning ANYTHING this approach will help.
I work on the basis that for every hour I spend PLANNING, I will save 1 DAY coding.
Pigmy
:cool:
...which is app. the same thing I usually do.
I did however try this approach on a somewhat bigger project (6-12 months work), and it didn't work very well for me. The problem is, that planning work more than 3-4 months in advance is fairly unrealistic since the specifications of a project has a tendency to change as you go.
I may be going a little bit off-topic with this one, but to me it's quite interesting. (Could always start a new thread, it's up 2 you guys :))
I am not very good at system design or oo-programming so I have tried looking into stuff like use-cases, uml and methodologies like extreme programming.
Any good suggestions about such topics?
BIW
I know this must sound pretty stupid, but (I'm only a beginner anyway...) : how would you write a module ? And what can they do? Do you know where I can get a tutorial on "writing modules"?Quote:
Originally posted by mxnmx
To increase code reusability use Standard Modules...I had a program in which I was to connect to SQL at every 3rd form...so instead of writing again n again...you could write it in a module and simply call it whenever needed...this prevents you writing the same code 10 times...
Thanks,
Andrew
You could also use VB's debug.print function instead of message boxes, so you will only see your messages while running the app in VB. Using message boxes would mean that you have to delete them before compiling the final app.Quote:
Originally posted by biw
A comment on Hobo's reply.
If you are able to, it is usually better taking advantage of VB's debugging features (breakpoints, step-by-step tracing etc).
Sometimes however you are not allowed to do that. At that point Hob's solution is a quite good one.
BIW
Hmm... as strange as it seems. Using messageboxes for debugging is sometimes used as a simple way for debugging, but they are usually best suited to debug quite complex cases, where the normal debug-features in VB is not too helpful.
I use messageboxes as a debugging-tool myself when
- I work with real-time systems (eg. hw that keeps running even if you pause your application)
- For debugging in some cases of strange behaviour. I mean those bugs, that you really want to blame on the mean spirit of your computer :)
- When the normal debug-features doesn't seem to help you pinpoint the problem, although you can verify a malfunction in your program. Messageboxes sometimes have an effect on the programflow just by being there. Sometimes it is a good thing, sometimes not.
I'm not a big fan of message boxes for debugging - they tend to stop program flow to thoroughly for my taste. Prefer Debug.Print and Debug.Assert statements....
I'm about to sit down and design a suite of integrated products that are going to be written over the next two years. It's a pretty big job, and I'm still getting the basics down, but this time around, at I've got the time and money to spend on the niceties of software development - proper analysis and design, decent configuration management (does anybody out there work with the Merant PVCS products? Email me if you do - I'm looking for opinions of it), decent support docuemtnation and the like.
I'm hoping that it will all go to plan, but trying to manage 6 coders over two years with staged product release is going to be pretty difficult.
- gaffa
Yeah me too... message boxes suck... debug or stop for me.
Is it too secret agent to ask what sort of software you are designing? Do u have ur own company or work for some wealthy land owner, who cruises around all year on his yacht with 50 or more nubile wenches? :eek:
Working towards the nubile wenches on the yacht, but so far all I own is my own company...
We are writing newspaper production software - basically layout software for newspapers, and booking software as well. Actually quite a lot of fun, cos the layout stuff isn't database stuff - striaght graphics work and AI, which is nice for a change. The booking package is DB though...
- gaffa
I to have found planning out my software before I even start coding allows me to be more efficient with my time, and produce better, more manageable code. I thought I was handycapped because I did this (need to do this for big projects), and I know a lot of programmers don't do it. It's nice to hear that this is something that others do.
Another point on the 'using msgbox's' idea for debugging, don't do it unless absolutly neccessary. Because it stops your code, you could be missing something that is really causing the problem. This happens a lot when doing async process calls to objects.
Always indent your code, it makes it readable.
Always name your variables to something readable. Don't name them obscure things unless you want your code unreadable.
Use OO development as much as possible.
That's all I got, thanks for reading.
Look up Hungarian Notation if you need help naming vars - consistent naming makes a huge difference....
- gaffa
Quote:
Originally posted by GlenW
I know this is pretty basic, but I've seen people not do it.
After typing;
You should type:VB Code:
Then put the body of the If statement in.VB Code:
Same for Whiles and Fors
After opening a Connection and Recordset, Close them, then add the code to use them.
I totally do this.
It makes sure I close the statments.
I also use comments in the body of a statement if nothing is supposed to happen (ie. planning to add stuff there later) rather than leaving it completely devoid.
if condition then
'ToDo: Add a bail out here
end if
same here. makes things so much easier.Quote:
Originally posted by Lord_Rat
I totally do this.
It makes sure I close the statments.
I also use comments in the body of a statement if nothing is supposed to happen (ie. planning to add stuff there later) rather than leaving it completely devoid.
if condition then
'ToDo: Add a bail out here
end if
also:
VB Code:
then put code between etc
A language-neutral set of guidelines
1. Code for human consumption
It is one of the most pervasive misunderstandings in computing that the source code is for the computer's consumption. Computers work with low-level binary code, a series of impenetrable 1's and 0's or hexadecimal numbers, not the structured high level languages we code in. The reason that these languages were developed was to help the programmer.
In practice, coding for human consumption means coding for clarity first, over execution speed second.
2. Comment often and comment well
The comment is the extreme example of a language element for human consumption. Most compilers will strip the comments from the executable program. The purpose of the comment is to tell you (and any future developer) what the program is intended to do. Write comments with this in mind - and avoid simply restating the code.
Good comment: "Disable button to prevent its activation". Bad comment: "Set cmd = False"
A good indication that you have got the level of comment right: could someone understand what your program does if all but the comments were removed?
3. Layout code to increase legibility
Just as it is important for an author to split a book into chapters and paragraphs that aid reading so it is important for the developer to consider the layout of the code and how that can aid readability of the code. In particular any code branch (an IF..THEN...ELSE construction) and any code repetition (a WHILE...END WHILE construction) should be indented so that it is easy to see where they start and end.
4. Expect the unexpected and deal with it
Before you open a file, make sure that the file is present. Before you set focus to a control, make sure that the control is visible and enabled. Try to work out what conditions could cause your code to fail and test for them before they cause the program to fall over.
5. Name your variables to aid readability
There are a number of strategies to variable naming. The key is to be consistent and to be as informative as possible. If you name a variable nMonth, you give the programmer extra information as to what that variable is expected to contain. I personally prefer the Hungarian notation style - but whichever style you use, consistency is the key.
6. Keep your functions and subroutines simple
A function or subroutine should ideally only do one thing. One of the greatest sources of misunderstandings, in my experience, is a subroutine that does a number of different operations. This should be split into separate functions for each different thing it is doing so that these in turn are easy to reuse, and the scope of a code change is easy to understand.
7. Scope functions and variables appropriately
Functions and variables that are only used in one module should not be visible outside that module. Variables that are only used in a function or subroutine should not be visible outside that function or subroutine. This prevents any use of a variable or function outside of where it makes sense to use it.
Speaking of which, one thing I was told a long time ago and I really find useful is that you should attempt to keep all subroutines and most functions to fit on the screen without scrolling.
If you get more detailed, make more subroutines. This helps when reading your code because whole proceedures are consolidated and if you are sure a section of code is working properly, you skip one line, and not a whole section.
This might be a little bit off topic, but I think it is related to good programming habits (at least for larger projects):
How do you make realistic time-estimates for your projects?
As good programming practice goes, I find that thinking in black-boxes helps alot. Even if you're not ready for OO-programming yet.
ummm... could someone help me out here? what does OO-programming mean? :rolleyes:Quote:
Originally posted by biw
As good programming practice goes, I find that thinking in black-boxes helps alot. Even if you're not ready for OO-programming yet.
I was thinking of Object-oriented programming in all it's glory (using classes,inheritance, polymorphism etc)
Objectoriented programming, usually involves using a specific feature of a programming language.
What I am saying, is that getting used to think in "black-boxes" helps your design, even if you only use standard vb-commands to implement your program.
I got a newer; more updated version of the speed tester.
It does find IF's faster than Select, now.
Please, test it out, see what you think.
Also, if you are curious, try putting in 40 million in the top box (40000000) and run it both in the IDE and as an EXE.
See the difference in speed.
Is the new program acceptable?
Is there anything else I should have done / not done?
You would have done differently?
I use this information to see if I have bad practices that I need to weed out of my style.
Thanks.
Here's one.
In visual Basic, I usually always give each new controls a unique and descriptive name.
Instead of using the defaults "command1", "command2" etc..
I would have renamed the buttonnames to "cmdRun_IF", "cmdRun_Select" and "cmdAverageBoth"
I have made a habit of that, so that I don't start off with default names, having to rename them later.
When you have many events on the same control, that makes the code just that much easier to read.
Very good feedback.
I actually normally do name Commmand Buttons as bnSomething, but I didn't here.
Thanks for pointing that out :)
Just a few tips...
- use cmdWhatever -- the "cmd" is the easiest to understand, "bn" might be misunderstood as something else
- sString instead of strString -- easier to type, cleaner names
- iInteger, lLong, etc. shorter is better
- make sure that double quotes (") are handled correctly and won't crash your program
- provide wrapper functions for most API's you use, especially when dealing with strings.
- denote functions as "clean" or "dirty" -- determines whether you need to validate data or not.
- comment functions by explaining what they should do -- what their purposes are.
- never use the End statement.
I'm too tired to think of any more...
Here's one for those of us, that have english as a 2nd language.
Name your variables in english, don't use your native language.
Native language is ok for comments though. :)
That way the code "reads" much better
Surprisingly many of the people I know, mix english and Norwegian (my lang) when writing code.
Whoops, I forgot about magic numbers. The only actual numbers in your code should be 1's. Rarely will you have a good reason to use other numbers, like a random 9 <-- that's called a magic number. Using constants instead. That way, you don't have to do search and replaces, which risk missing things or changing things that should not be changed. Not to mention that using named constants makes your code more readable.
Hmmm.. didn't quite catch that. Care to elaborate? Example maybe?
I think this topic deserves a good bump :D