Not all syntax coloring is created equal

Syntax coloring for programming languages was originally introduced as a visual aid to assist developers in assessing the syntactical correctness of code. Unlike the squiggly red or green underlines in Microsoft Word colors indicate validation rather than error. So while glancing at a syntax colored stretch of code the usual green hue of comments and reddish string colors enclosed in double quotes quickly instill a sense of the structure to the code. Commands are colored in certain specific colors and indicate that the system is aware of them.

Traditional programming languages, like C/C++, have only a very few keywords, so the coloring is mostly pretty sparse.

image

Typical C++ code sample in Visual Studio 2008

 

With the introduction of the .NET framework and type reflection, IDEs and editors where suddenly able to color new types of keywords.

image

Typical C# sample in Visual Studio 2010

 

The first thing you will notice when comparing these two screenshots is that for C# types are now colored as well.

This entire syntax coloring mechanism not only serves as a visual aid when analyzing existing code, it also assists when writing code. Users of modern IDEs and editors have become very accustomed to keywords changing color as you finish the word and hit space.

image

typing a cmdlet just before finishing it

image

after finishing the cmdlet

 

Most us give pause to typing when we notice that the previous word typed did not change color and become bold as we moved on to the next word.

Now, recently we received an email from a customer complaining that PrimalScript 2012 does not color .NET types in PowerShell. Or type accelerators for that matter. Which is true and once we were reminded of that we immediately went and implemented that feature. It was rolled out in service build 6.5.141.

image

.NET type and accelerator coloring in PrimalScript 2012

It was also pointed out to us that the PowerShell V3 ISE does color .NET types and that we should really get moving on this. Not that we needed that additional incentive, but it caused us to give that part of the ISE a closer look.

image

.NET Type and accelerator coloring in PowerShell V3 ISE

There is the big problem though. The ISE is completely faking it. Anything inside square brackets is colored as a type.

image

ISE colors anything inside a square bracket as type

What’s even worse than that, anything typed is colored as if it was a command.

image

non-existing cmdlets colored nonetheless

 

If you look at the same stretch of code in PrimalScript 2012 you see that the non-existing types and cmdlets are simply not colored.

image

Now, mind you, in the real world that can mean that these types and cmdlets simply don’t exist on the local machine but are perfectly valid on the intended target of that script. PrimalScript provides a mechanism for adding types and cmdlets from remote machines and dynamically switching between them.

That allows you to use syntax coloring the way it was intended to be used; to help you code better and with less errors.