In a previous blog post we already took a first look at “Fix-It” support and some related editor enhancements centering around error reporting that are coming to Prism XE2 and Project Cooper later this fall.
Today, I want to focus on one specific new detail in error reporting that – while not technically tied to fix-it – certainly is made possible and useful by it. And that is spell checking, or more precisely the detection of mistyped identifiers or keywords by the compiler.
As most of my readers know, my own typing skills are particularly bad
All that is a thing of the past with Oxygene 5’s new Spellchecker feature, as can be seen in the following screenshot:
But let’s look on:
#2: As the code continues, there’s two lines of code that try to call methods on our “x” variable. Using old Oxygene (or any other number of languages), you’d get two errors on this code, as the compiler would tell you that, since it doesn’t know what type “x” is, it certainly won’t let you call “ToLower” or “ToUppper” (sic) on it. Which is silly, if you think about it – if the compiler doesn’t know what type “x” is, how can it even begin to know what you can or cannot do with it?
Oxygene 5, instead, gives you only one error, on the call to “ToUppper”. Which makes sense, because “ToUppper”, with three “p” doesn’t actually exist on Strings, and the compiler figured, from the previous error, that “x” pretty likely is supposed to be a “String” (had we not mistyped “ToUpper”, there would’nt be any follow-up errors at all).
There’s really two benefits here, disguised as one: (a) you’re not getting overloaded with bogus error messages that are follow-ups of a badly typed name and (b) much more importantly – you do get reliable error messages for things that actually are wrong. So you can fix both typos in one go and move on (normally, you would most likely have missed the error on “ToUppper” until you fixed the first one and hit rebuild again).
Note that, indicated by the little “Magic Wand” icon, the spell checker of course kicked in for “ToUppper” as well; if your code had been more complex, say assigning the result of “x.ToUppper” to a new variable and doing more work with it, all of these benefits would keep cascading down into the rest of your code.
#3: Finally, and an improvement that’s very dear to my heart, you see at the very bottom of the screenshot that Code Completion is fully functional on “x” as well. That’s a huge productivity boost, as you can keep writing your code, and deal with the typo once you are finished – while under the old compiler, you would have to stop your current thought process, hit build (possibly, to even find the error) and fix the error. That, or carry on writing code without useful Code Completion, which is never nice.
Being the keyboard-dyslexic I am, I am really excited about these enhancements to the coding flow, and I’m sure I will benefit from this daily, if not minutely. I hope you will find this helpful, as well – let me know what you think!