Good Practices in Stable Coding???

[SineX]

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?

[Hack]

Make sure you have tight control over sub routines calling other sub routines. Subs running amok can cause all sorts of nasty issues.

[Cander]

set object to nothing when done with them is a good one

try to avoid loops within loops if possible.

[SineX]

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.

[darre1]

dim obj as Object 'declare object

set obj = New Object 'create instance

'you coding with object


set obj = nothing 'destroy instance

[darre1]

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

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)

[MerrionComputin]

Also writing some "bulletproof" functions, such as:

Public Sub SafeSetFocus(ByVal ctl As Control)
   
   If ctl.Visible And ctl.Enabled Then
       ctl.SetFocus
   End If
End Sub

[biw]

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

[DerFarm]

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.

[Lord_Rat]

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.

[mxnmx]

Use comments for every statement that you thinkwill help you to remind in case you get out of touch...

[The Hobo]

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.

[DerFarm]

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

[Lord_Rat]

Commenting is ESSENTIAL.

For the most part, more is better. Don't write books though.

[MartinLiss]

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
  

  '*** 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.

[beachbum]

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

[MartinLiss]

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.

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.

but if the statements are in a time critical loop or such then go for the If Thens which again are much faster.

Are you sure? It may well be true, but I was wondering if you have actually ever timed it.

[beachbum]

Originally posted by MartinLiss
Are you sure? It may well be true, but I was wondering if you have actually ever timed it.

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.

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

[Lord_Rat]

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?

[Lord_Rat]

P.S. make sure you use a large number, like 4 million.

[beachbum]

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

[Lord_Rat]

OK, stay tuned . . .

[Lord_Rat]

So, how do I use GetickCount?

[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

[PeterPigmy]

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

[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...


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

[The Hobo]

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.

[nabeels786]

Originally posted by Lord_Rat
So, how do I use GetickCount?

Private Declare Function GetTickCount Lib "kernel32" () As Long
 
    Dim ret As Long
    ret = GetTickCount()

[beachbum]

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...

Yeah and i even started a birthday thread for you but it was a pub hol weekend and so died in the arse

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.

[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

[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

[GlenW]

I know this is pretty basic, but I've seen people not do it.

After typing;

If(CONDITION)then

You should type:

End If

Then put the body of the If statement in.
Same for Whiles and Fors

After opening a Connection and Recordset, Close them, then add the code to use them.

[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...

[PeterPigmy]

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

the way I do it is to start off with good old Systems Analysis.

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

[biw]

...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

[daemon666]

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...

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"?
Thanks,
Andrew

[daemon666]

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

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.

[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.

[gaffa]

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

[beachbum]

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?