Why You Should Learn to Love Syntax Errors
Syntax errors are the quickest and easiest type of bug to fix.
A syntax error is nothing more than an invalid combination of programming "tokens." There are several steps to compiling a high-level programming language into instructions that a processor can execute. The first step is parsing.
Parsing is the process of reading through a block of code and assigning "roles" to chunks of characters.
These "roles" (a.k.a., "tokens") are things like 1) keywords, 2) identifiers, 3) literal values, etc. Part of the parser's job is to make sure these tokens appear in a sensible order. What is considered "sensible" varies from language to language. The specification of the sensible order of a set of tokens is what is known as the language's syntax.
A syntax error results if you arrange a language's tokens in an invalid order.
Syntax Errors are Very Easy to Fix
Syntax errors provide immediate negative feedback.
Even the VBA IDE, the creakiest of all modern development environments, includes support for realtime language parsing. Enter a syntax error in your VBA and when you move to a new line, the IDE will set the font color to red and show an annoying message box (which thankfully can be disabled via Tools > Options > [ ] Auto syntax check).
Why is it instant negative feedback good?
It's good because the biggest cost to fixing bugs is loading context. Before you can start fixing code, you need to understand the context in which it runs. If the code you are trying to fix is something you wrote several months ago–or isn't even your code–then it will take a long time to figure out where it fits in with the surrounding code. This is why runtime errors can be so expensive to fix.
Since we learn about our syntax errors as we make them, they are quick and easy to recover from.
Syntax Errors are Most Common when Learning a New Language
Typos aside, I almost never write syntax errors in VBA.
This does not make me particular special, it just means that VBA is my "native" programming language. I occasionally write code in other languages, such as C# or Python. When I first start writing in those "foreign" languages, I can barely go ten minutes between generating syntax errors.
However, if I immerse myself in the language–such as when working on a non-trivial project–I become proficient enough to avoid syntax errors in about a week.
Syntax Errors Help Programmers Learn New Languages Quickly
The reason I learn so quickly is because of the instant negative feedback loop:
- Attempt to write code
- IDE warns me about invalid syntax
- Google correct syntax
- Write the correct code
- Repeat step 1
This immediate feedback drastically reduces the amount of time needed to learn a new language–at least at a superficial level.
Don't Fear New Languages...
The biggest stumbling block when learning a new language is dealing with syntax errors. But syntax errors are the easiest types of bugs to fix. Here's the order:
- Syntax errors
- Compile errors
- Misunderstood requirements (before you start writing code)
- Automated test errors (i.e., failing tests)
- Runtime errors
- Misunderstood requirements (after you've written the code)
- Logic errors
The best programmers are those that have developed techniques to reduce the frequency of logic errors and runtime errors and do a good job of planning and understanding the requirements of the system before writing code.
Those are all skills that transfer among programming languages.
The errors you are most likely to make when learning a new language are those that occur at the top of the list (syntax errors and compile errors). But the skills and techniques you are likely to learn from the new language are those that help you avoid bugs that occur at the bottom of the list.
For example, here's a brief list of techniques I've imported into VBA from other programming languages:
...And Don't Hire Programmers Based on Language Proficiency
One of the great examples of market inefficiency in software development are companies who artificially restrict their talent pool to developers who know the specific language primarily used in-house.
A great developer can learn a brand new language in a matter of weeks. Furthermore, that developer will find ways to incorporate the best parts of their "native" language into their new technology stack.
Of course, if you run a Microsoft Access development shop (like me), then hiring non-VBA developers is practically a requirement as there are so (relatively) few of us around anymore.