Advanced Excel Development, Training and Support

 
Products for Excel
Commercial Products
Spreadsheet Quality Products
Free Products
Spreadsheet Services
Spreadsheet Development
Spreadsheet Migration
Spreadsheet Maintenance
Spreadsheet Review
Spreadsheet Management
Excel Development
Excel Developer Types
Excel VBA
Excel and Databases
Excel and Pivot Tables
Excel Add-ins
Worksheet Functions
Excel and xlls
Excel (in)security
Excel testing
Excel and .net
Excel VBA IDE (editor)
Excel VBA Training
Professional Excel Development
Excel 2007
Resources
Consultant Profile
Book Reviews
Links
Other

Working with Excel and VBA

Simons VBA Best Practice Slides are here.

There are several good reasons to avoid VBA, the main one being the likely multiple copies of code that will end up in circulation as the host workbook is duplicated and adapted. COM add-ins with either VB6 or .net, or xlls with C++ do a better job in this respect. From a speed of development and initial deployment point of view though, VBA is superb.

Once the decision has been made to use Excel and VBA, one area that can have a dramatic effect on productivity and code quality is the set up of the VBA IDE (Interactive Development Environment) (editor).

VBA Environment

Unfortunately the default environment settings are not geared towards high quality development, they are set to make it easy for beginners to get productive quickly.

These are our preferred settings for professional quality development (Tools>>Options)

The default is to have those top 2 reversed.

You always get Auto Syntax Check (line goes red), removing the tick stops the disruptive modal error message boxes from constantly popping up every time you move off a line to copy something:

If the advice were a bit more helpful it might be worthwhile, but even beginners would struggle to get any value out of the above example. And it isn't going to get better as VBA is end of lined. Advice: Turn off Auto Syntax Check.

Require Variable Declaration puts an 'Option Explicit' at the top of each new code resource you open (module, class, form etc) (note it is not retrospective, hence the need to set it ASAP). Not using option explicit is just sloppy and is sure to lead to hard to spot errors in any significant coding.

if you want to use a variable called x (you may be able to think of a more meaningful name) OE forces you to 'Dim' it first, and optionally to decide what data type it should be. If OE is missing VB will implicitly Dim the variable as a variant the first time you use it, if you later mistype the variable name VB will create another new variable, rather than warn you 'Variable not defined' which would be more useful.

Note these settings will be reflected in other Office applications.

Much more info is included in these slides.

VBA Security

There are two main aspects to security

  1. Potential loss of intellectual property if people access source code without permission.
  2. Potential danger from a malicious user subverting the expected behaviour for their own (possibly disastrous) purposes.

VBA security is fairly poor, the code is not compiled, and the source is available in the excel file. The password protection is pretty easy to circumvent. This reflects Excel/VBA target as an end user application. Code security can be enhanced by moving to COM components or C, if there is a real need.

Please contact us with any questions.

This page was last reviewed on July 31, 2007

©Codematic Ltd 1999-2007