Not all syntax coloring is created equal

• PrimalScript

User Rating: 5 / 5

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.

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.

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.

typing a cmdlet just before finishing it

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.

Back in 2012, we received an email from a customer complaining that PrimalScript did not color .NET types in PowerShell. Or type accelerators for that matter. Which was 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.

.NET type and accelerator coloring in PrimalScript

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.

.NET Type and accelerator coloring in PowerShell V3 ISE

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

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.

non-existing cmdlets colored nonetheless

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

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.

• Prev
• Next