Application Security Testing: An Integral Part of DevOps
Visual Basic was created as a rapid application development (RAD) tool, yet the default IDE settings of Visual Basic do not lend themselves toward effective coding and often result in unnecessary time wastage.
It took me a while to get Visual Basic to behave the way I wanted it to, but eventually I got there. Working with Visual Basic is now a pleasure in comparison to what it was the first time I installed it. Now, every time I work on a machine other than my own, the VB IDE just gets infuriating.
I thought I would share some of these "tricks" with you. Some are about setting up the IDE and others are just ways of coding which work for me.
Dim or Dim-wit?
Ah, the battle rages on as to whether or not to force one's self to use declare all variables before they can be used. I'm sure any one who has used Visual Basic for any amount of time will know the debate over the Dim statement. Let me outline the advantages for both sides of the argument, and then you can make an informed decision yourself.
For variable declaration:
You won't spend hours tracking down a spelling mistake in a variable.
Variables can be declared in multiple scopes all sharing the same name.
Best coding practices all suggest using it.
Against variable declaration:
It can save about three seconds per variable (but could spend hours debugging a spelling mistake).
...that's about it.
Guess which one I subscribe to! Yet, with everything pointing toward forcing variable declaration somehow Microsoft still thought it would be a good idea to turn it off.
So, the first thing I would suggest in VB is to set the "Require Variable Declaration" setting found under "Tools -> Options... -> Editor".
Auto Check Syntax
Once you have used Visual Basic quite a bit, you'll start to find that that flipp'n popup (that appears each time you move off an incomplete line) starts to get really annoying. For example, if you type "if then" and move your cursor off this line, a warning pops up telling you it is an illegal statement.
You can prevent this popup up unchecking the "Auto Syntax Checking" setting. This setting shouldn't be used by beginners because it often helps you to quickly identify incorrect syntax, but after you've been using VB for a while it is time to let it go.
Compile On Command
Found under "Tools -> Options... -> General," the "Compile On Demand" setting has to be one of the most infuriating settings in VB. In a nutshell, what it does is, when running code from the IDE, a line of code is only compiled once it is reached, which sounds like a good idea... at first. But, what happens is, you are nicely stepping through you code and then BANG, it breaks because there is an error on the line you have reached. So, you correct the error and then start again with your testing.
Plus, any code you never reach (for example, error trapping) doesn't get compiled, so you never see some error creep in. To see what I am talking about, try the following. Make sure "Compile On Demand" is on and then make a new project, inside which you place the code:
Private Sub TestProcedure() Hello End Sub
This shouldn't work because "hello " is not defined. But, run the code and it works fine. At least, it will work until you reach this procedure. Only then will it complain.
On the first big piece of code I wrote, everything seemed to work and so I decided to build my exe. But once I did, it took ages to go through all of the bugs that had crept into my code.
These headaches can be avoided by turning off "Compile On Demand." It doesn't take a machine long to compile your program, and the saving at the end of the day is worth every last millisecond.