Jonathan's Blog

50 Reasons Why .NET is Better Than VBA

Type Safety

1. PLEASE, for the love of dog, type-safe collections!
2. In VBA, you are not required to declare the type of a parameter. This makes it possible to overlook this step, and the Variant you'll get by default has poor performance.

The Library

1. A comprehensive and modern library, with consistent interfaces and an OOP paradigm.
2. A Timer class for quick and easy profiling.
3. VBA's Dictionary is case-insensitive for the Exists() method, but case-sensitive (by default anyway) for Item()!
4. Better text streaming; VBA's TextStream class is an obscene memory hog.
5. .NET has tidier, more rational controls (e.g., ComboBox.Items.Clear(), and the ability to populate a ListBox with objects).

Object-Oriented Programming

1. Inheritence. Not necessary in every project, but hugely useful when needed.
2. Secure alternatives to module-level variables.
3. Constructors with parameters.

Language Capabilities

1. VBA's largest integer data type is a signed 32-bit, so values greater than two billion (e.g., phone numbers), have to be stored as Double.
2. .NET supports true multithreading.
3. The ability to compile utilities into a DLL.
4. Static functions, so helpful for factory methods.
5. Simple passing and returning of arrays.
6. Templates.
7. SQLParameters, for more robust handling of strings and dates and reduced risk of injection.
8. Donated static methods (what are these called again?).
9. Methods with variable parameter lists.
10. Better string functions.
11. Flexible "for" structures.
12. Custom iterators.
13. VBA passes parameters by reference by default, making it easy to accidentally cause an obscure side effect.
14. Fail-fast logical evaluation.
15. The yield command, for simple and efficient looping over non-standard collections.
16. Nullable types are a great convenience when working with databases.
17. Speed. VBA is astonishingly slow at simple tasks like reading from an ADO source and writing to local, or reading from local into memory.
18. VBA does not implicitly cast even when it's perfectly safe: you must manually cast an int to a long, for example.

Exception Handling

1. Stack traces!
2. Specific catch blocks.
3. Easy recursing for nested exceptions.
4. If VBA breaks at an Err.Raise, you cannot change or comment out the command. Nor can you simply swallow the error and continue. Your only option is to exit and start over.

The IDE

1. Refactoring tools.
2. Better navigation: more robust go-to-definition and better file setup.
3. Code folding.
4. Line numbers in the IDE.
5. A stable IDE. Access gets flaky sometimes, and specifically has a bad habit of polling all properties for the Locals window, even though some may not be quick or low-impact. The workaround is to put these into methods instead. Worst of all is when it actually corrupts your code; the workaround is frequent backups and small modules. This is NOT a problem for real languages where the code is stored in simple text files.
6. Integration with Visual SourceSafe. As awful as it is, VSS is better than nothing.
7. Automatic TODO lists.
8. Warnings for unused params and locals are very handy.

Cosmetic Preferences

1. Using "return" rather than a function's name.
2. Being able to declare and assign a variable in one statement will be a relief.
3. Block-local variables.
4. The "continue" command for short-circuiting loops.
5. The ability to horizontally align run-on parameters, operators, etc.
6. Consistent use of parentheses around the parameter list for all methods, which also eliminates the risk of confusion between calling method Foo and references variable Foo.
7. There would be no more need to remember to use Set for objects.
8. Long string literals.
9. The trinary operator. Yes, it can be abused, but sometimes it's much simpler and clearer.
10. C#'s case sensitivity allows one to distinguish between fields and properties.
11. VBA's implementation of if logic, especially else-if, is clumsy and verbose.