Learn about the various error finding habits of Delphi developers and how you can overcome bad habits to find errors faster and more efficiently
(Originally published at delphi-expert.com on May 1, 2004)
What's new?
We just released Castalia 2.3, which includes support for the new Delphi 8 for the Microsoft .NET platform! Details are here.
Spend less time finding errors
In the course of our research, we discovered two common patterns among developers in the way they find syntax errors. Developers who do not use Castalia tend to fall into one of two groups:
The first group will write a small amount of code - a single line or a short procedue - and then complile the code to make sure that it compiles.
If it does not compile, they will fix the first syntax error, and then recompile, repeating the pattern until all syntax errors are fixed. They then move on to the next line or small group of lines, and compile again.
The second group will write a significant amount of code - often entire classes or even complete units - and then compile them. Very frequently, the compiler will discover a number of syntax errors: missing semicolons, unmatched parenthesis, mismatched begin..end blocks, misspelled identifiers, etc... The programmer will fix the first error, then recompile, fixing the first error each time, until there are no more errors. He will then test the code and, when satisfied, move on.
We found that Developers who used Castalia's syntax checking facilities were able to reduce the amount of time spent in this compile-read-fix-compile cycle.
To reduce time spent finding errors, make sure that you are using Castalia's live syntax checking. This will draw a squiggly red line under syntax that doesn't meet the Delphi lexical standard for compilation. When you see a squiggly red line, you know something is wrong. If you can't immediately identify what it is, put the cursor into the word that's underlined, and a balloon hint will appear telling you precisely what the problem is. In the example here, a semicolon is missing right before the underlined word.
Next week, I'm going to write about the results of our investigation into the way developers interact with and navigate through existing code.