Getting started with Roslyn

I heard about Roslyn recently. No, not the Rosslyn from the Da Vinci Code, Microsoft Roslyn, the project which exposes the C#/VB compiler APIs allowing all kind of code analysis, generation and refactoring goodness, amongst other things. Interesting stuff. 

It took me a while to get going with Roslyn so thought I'd record some stuff I found useful. 

First things first

After downloading Roslyn read the project overview whitepaper. Finished? Read it again. The core concepts are pretty fundamental.

Installed with Roslyn is a handy getting started guide. 

Of course I didn't realise this at first *face palm* so I stumbled along blindly for a while. Arguably the most useful inclusion is the Syntax Debugger Visualizer. With this you can explore syntax trees by clicking directly on the code which jumps to the appropriate section of the syntax tree. To view the visualizer click on the magnifying class when debugging a syntax tree or node variable. Here's more information on the Syntax Debugger Visualizer.

Also included in the getting started guide is more documentation and a lot of example code. It's worth taking time to look through both of these. I wanted to write a quick fix, so the make const quick fix sample was particularly useful, as were unit test and tree transformation samples.

Creating code programmatically

The Syntax object can be used to create nodes and tokens. E.g.

Generally I've found it easier to generate statements/syntax trees/whatever from code strings. There are a whole bunch of ParseXyz methods.

Finding stuff in the syntax tree

One way to find nodes/tokens/trivia in a syntax tree is simply to use the Syntax Debugger Visualizer to understand the structure then write your query based on that information. LINQ is your friend. As well as DescendantNodes also look at methods such as Ancestors(), DescendantNodesAndTokens() and DescendantTrivia().

Finding a variable type

The semantic model can be obtained by calling GetSemanticModel from a Compilation or IDocument object. Other ways may be available.

Altering code

There is a lot of ways to alter code. Bare in mind that all Roslyn objects are immutable. The methods I've used the most so far are things like ReplaceNode, RemoveNode, ReplaceToken, RemoveToken etc. In addition there are several With* methods. E.g. WithBlock, WithClassDeclaration. In Roslyn a "block" is exactly what you would expect. I.e. A section of code between two curly braces.

It's worth noting ReplaceNode is an extension method and will only be visible if Roslyn.Compilers and Roslyn.Compilers.CSharp are referenced.

Formatting code

When inserting new code into a syntax tree the formatting will be terrible. You can fix it manually by inserting the relevant trivia. Don't bother. Format() method for the win.

Enabling Roslyn in Visual Studio

One gotcha to look out for. If you write a Roslyn extension then install it, the extension will not work unless Roslyn is enabled. This had me scratching my head for some time. By default Roslyn is only enabled in the debug instance of VS fired up when you run a Roslyn project. To enable it add "/rootsuffix Roslyn" to your VS shortcut. How do you know Roslyn is enabled? Each code tab will include "[Roslyn]". Thanks to Stack Overflow for that tip.

DDD North 2012

I had a cracking day at DDD North so thought I'd write up some of my thoughts on the talks I attended.

10 practices that made me the developer I am today

Garry Shutler presented this talk. It struck a chord with me, particularly his experience of leaving university without a bunch of fairly important skills. All the topics covered were relevant. For the most part they were familiar. If I were to draw up a list of ten practices I believed made a good developer it would share many of the same points so it's nice to know someone with more experience than yourself values similar practices (it gives me a warm fuzzy feeling). There were several topics covered which I don't do and they were food for thought. You can find a brief summary of the talk here.

Async C# 5.0 - patterns for real world use

This talk was basically an introduction to C# async, or magic as I like to call it. The code looks like regular linear code, but it's not. Liam Westley covered the basic keywords, some examples and some gotchas. Interesting stuff.

BDD - look ma! No Frameworks

Out of all the talks I attended this one caused my brain to hurt the most, in a good way. In the hour Gemma Cameron introduced us to Behaviour Driven Development (which I previously knew nothing about). If I understand correctly BDD is kind of a mix of TDD and DDD. One of the important aspects of BDD is communication. Talking to people, speaking in their language, finding out what they want, working out their motivation, all with aim of making software that people actually want. Another important aspect of BDD is how you test. As I understand it the idea is to write tests than can be read by a non techy. This means that firstly the tests should be readable, using words that will be understood outside of code land, and secondly the tests should be top down, meaning they should test a behaviour rather than a method of a class. Obviously there is more to BDD than these two points, but these are the main things I took from the talk. 

To be honest I didn't leave convinced. My impression of BDD is that it's a mish mash of other things. Communication is important, but it's by no means the only software development process to promote it. What about the testing aspect? To me it sounds like a automated acceptance testing which again isn't new. I feel there is benefit from this kind of testing but my preference would be alongside unit tests rather than instead of. Another problem I had was that I can't get my head round how I would apply this to a complex example. How would I write this kind of test in my code base at work? I have no idea. With difficulty I would imagine. 

One other topic, mentioned briefly, not specific to BDD is the self shunt pattern. Apparently this is a technique which can be used rather than mocking when unit testing. It's now on my reading list.

Javascript sucks and it doesn't matter

There was a large amount of stuff covered in this talk by Rob Ashton most of which I'll not use as I don't write a great deal of Javascript, but very interesting none the less. The most useful thing I took from the talk was that qUnit isn't great for writing unit tests that have a large amount of DOM interaction, something I've previously tried to do. A much nicer way of doing it is using a headless browser called zombie.js. Another one for the reading list. Here is a summary of the talk.

C# + Powershell = happy couple

Unfortunately I was half asleep at this point in the day. Getting up at six o'clock doesn't agree with me. Still it was intersting. Jimmy covered the basics of writing your own Powershell cmdlet in C#. Turns out it's fairly straight forward and potentially very useful. I say potentially because I can't think of any useful cmdlets to write. I will though, eventually.

Book review - Mastering Mountain Bike Skills

If Mountain Biking The Manual was the starter, Mastering Mountain Bike Skills would be the main course. I re-read this book recently and I think it's fair to say I'd completely forgotten how good it was. As with The Manual, it's jam packed full of incredibly useful information that is very well explained. But importantly, it succeeds where The Manual fails. There are diagrams and photos of everything. Want to know the correct attack position? There's a photo of that. Not sure of the best line to take through a switchback. There's several diagrams for that. Want to know which part of your bum rests on the saddle? There's a diagram for that! It's difficult to overstate how useful diagrams and photos are when trying to visualise an unfamiliar technique, and for me visualisation is one of the best ways to start the learning process.

What topics are covered? As with the Manual all the basics are there. Attack position, braking, cornering, flow, jumps, drops, pumping, bike setup, the list goes on. Certainly everything I want to know is clearly explained with a bunch of diagrams/photos. I had several eureka moments when reading MMBS. "Oh right, so that's how you're supposed to do it!", "Ahhh so that's why pumping makes you faster!" If you had been in a room with me you would have seen a lightbulb appear above my head, on more than one occasion. In addition, at the end of each chapter is a troubleshooting section. Common problems and the solutions. Really really useful stuff.

There's something else I like about MMBS. Don't be fooled into thinking it's just a dry text book, it has personality, by the bucket load. Several pages made me smile. Here are a few of my favourite quotes:

On exploring the limits of your cockpit:

"Push back until your arms straighten or your bum gets the knobby treatment."

On braking during a corner:

"If a unicorn suddenly appears if your corner, first straighten out; then brake hard. If you've been practicing your braking skills, you'll be under control before you strike the magical beast."

On doing a wheelie:

"Explosively push your torso upward and backward with your arms. At the same time, uncork a powerful pedal stroke. If you are nice to puppies your front wheel will pop up."

To summarise; great explanations, lots of diagrams, buy it now.