Face Off - Code Syntax Highlighters Battle to the Death!

Or maybe not.  A while back, I blogged about the code syntax highlighter I was using and the various issues I had with it.  Over the past two months, I have tried several other code syntax highlighters, and thought I would summarize my experiences with them now.

Code Syntax Highlighter	Looks OK in Blog?	Looks OK in RSS feed?	Client -side Processing?	Modify after posting?	Blog Post
Insert Code – a Windows Live Write plugin.					Send Outlook Email Via Powershell
BlogTrot Code Window – An online tool to generate HTML for your code snippet.					Sending Gmail via PowerShell
NeatHighlighter - Similar to BlogTrot.					Send Outlook Email Via Powershell – since updated to use BlogTrot.
Google Code Prettify – A JavaScript library.					PowerShell and Arrays
Source Code Formatter – Another Windows Live Write plugin.					Fevered Coding

The overall winner is the Google Code Prettify library.  It is the easiest highlighter to use and allows you to quickly modify the display of your code snippets after posting by updating the relevant CSS file.  As it makes use of JavaScript processing on the client-side to produce the highlighting effect, the code is simple plaintext in the RSS feed, but still of an acceptable appearance:

I’ll be using the Google Code Prettify library to highlight all code snippets going forward.

The BlogTrot Code Window rendered the code on screen the best of all the highlighters tried, and the options to print and view as plaintext were also useful. The rendering in the RSS feed was poor, however, and the HTML produced could not be easily modified after posting.

It is worth noting that Scott Hanselman has recently blogged about using Syntax Highlighters again.  The one option he considers that I haven’t yet tried is hosting my code somewhere like GitHub, or Snipplr.  If you have tried one of these repositories to store and display your code snippets on a blog, please add a comment below!

PowerShell and Arrays

I came across a strange feature of PowerShell recently.  When dealing with an array that held a single item, I was very surprised to see that the count of items was over 1000.  To illustrate the problem, consider the code below:

		
$files = Get-ChildItem C:\Temp
# Single file present in target folder

Write-Host "Total number of files: $files.Length"
# $files.Length returns value in 1000s
		
for ($i = 0; $i -lt $files.Length; $i++)
{
	$file = $files[$i].Name
	Write-Host "Processing $file"
}

When the code was run for the case when there was single file in the target directory, the count came back in the 1000s. The script then raised an exception for each of the 1000s of times it attempted to reference files[i], when no such array index existed.

It took some digging to realise that what was actually happening was that when PowerShell returns a collection with one or zero items in the collection, it unpacks the array and returns the item (or $null), and not an array.  So in the instance above, by calling $files.Length, the script was returning the length of the file object in bytes, and not the size of the array. 

To correct this behaviour, simply wrap the call generating the array with @(), as shown below:

		
$files = @(Get-ChildItem C:\Temp)

This will have no effect if the call returns an array with more than one item (i.e. you will not have an array wrapped in an array). See this StackTack answer from Keith Hill for a more detailed response:

Also, just to note that the code for this post was highlighted using the Google Code Prettify JavaScript library.