 |
Visual Basic Programming - Avoiding Bugs
|
1) Free your resources in the exit block of code, that way if an error
occurs they are still released.
2) Document what the procedure does before writing it - this focuses you
on exactly what you are trying to achieve.
3) Write you test plan before writing your code (Nobody always does this
but it does lead to better quality code and easier testing)
4) Avoid "Resume Next" and using a standard error handler without
thinking of the consequences. This is often used and the developer
thinks "great, that's the error trapping done". Some times
using a standard piece of code can do more harm than good. Always
think, what errors could happen, and then trap them explicitly.
Also think, what happens if I resume next? Should I exit the function
instead? Should I raise an error to the calling function, or return
a value to indicate an error?
5) Automate testing wherever possible
6) Keep things simple - a procedure should do one thing and one thing
only, it is then very simple to test if it is doing that thing correctly.
7) Remote testing is a great laugh (Useful when you want to test/debug
on a clean machine as the development machine does the debugging but the
actual code is running on the clean machine).
The bug you will never repeat twice
8) Leaving out the rsTemp.Movenext statement when moving through a recordset.
9) Setting the incorrect threading model when writing COM components for
a web server
These are my own views and some of the things I don't do all of the time,
but should.
|
