The debugger evaluates property getters when showing it’s locals and autos windows. While this feature is indispensable in most cases, it plays havoc with our property-with-side-effects. What the debugger does is call the getter to present it’s value in the autos window, at the same time firing our code that has a side-effect. From there you have pretty confusing behavior with code seemingly running itself.

My exception to the rule is mutator properties in a fluent interface. You can often find properties in fluent interfaces that when touched alter the behavior of the next method called.

For example:

string value = null;

Is.Null(value)      // returns true
Is.Not.Null(value)  // returns false

The Is class would contain a value tracking whether the next call would be inverted or not, and the Not property would flip that value when called.

Now assume this, you’re using Is.Null(value) and you set a breakpoint on it. Your autos window has expanded Is and shows the Not property, what’s just happened? The debugger has now called Not and altered your state! Undesirable.

DebuggerBrowsable attribute to the rescue; this attribute when used with the DebuggerBrowsableState.Never parameter instructs Visual Studio to never inspect the property you apply it to. Your property won’t appear in the autos or locals window, and if you expand the tree of an instance containing the property it will show up with a Browsing Disabled message; you can then force it to evaluate the property, but at least it doesn’t do it automatically.

private bool inverted = true;

[DebuggerBrowsable(DebuggerBrowsableState.Never)]
public Is Not
{
  get
  {
    inverted = !inverted;
    return this;
  }
}

Sticking the DebuggerBrowsable attribute on your Not property prevents the debugger from hitting it and inverting the switch.

So there you go, if your property-with-side-effects is being invoked by the debugger, you can use the DebuggerBrowsableAttribute to prevent it.

By the way, I’m not advocating properties with side-effects…

Cross-posted to Los Techies

Git has been gaining a lot of traction lately, and rightly so. I’ve used it for a couple of years now, for all my projects (Fluent NHibernate and Docu being the prominent ones), but something that hasn’t changed is the tag-line of “but Windows support isn’t very good!”. What you quickly learn is that when people say that, they actually mean there isn’t a Visual Studio plug-in or some similar all-singing all-dancing GUI; this is a dire misrepresentation of Git, because it’s tooling on Windows is excellent if your definition of tooling includes the command-line.

It’s something ingrained in Windows developers, they hate the command-line. There’s a very good chance that if you encounter a Windows developer that does enjoy using the command-line it’s because they’ve also worked on another platform or in another environment that encourages command-line use (Rails is a good example). I’ve tried various ways of encouraging people to experiment, but very few work without being able to sit down and just show them something. It’s very much like R# adoption, nobody thinks it’ll speed them up until they see how fast someone else can be.

Back onto Git. If you don’t like what Git does, then that’s fine, but don’t label yourself as Alt.Net or a continuous improver if this sounds like you: “I define myself by choosing the best tool for each situation, but there’s no way you’ll get me using the command-line.” Way to go, oh open-minded one. Try it, you might like it.

The other techies have been posting some great Git posts which can help you get up to speed. I hope to contribute, with less bile, soon.

This post could’ve also been called “Fluent NHibernate secrets exposed!” but it sounded a bit sensationalist.

You may have heard people mention static reflection recently, quite possibly because it’s used extensively in Fluent NHibernate, Rhino Mocks, and I believe Jimmy Bogard’s new AutoMapper also uses it; pretty much any of the new “fluent” interfaces use some kind of static reflection.

So what actually is static reflection? Well, it’s a statically compiled way of utilising the Reflection API.

Traditionally, if you wanted to use the Reflection API to interrogate your classes, you’d need to utilise strings to refer to properties and methods; this can make your design quite brittle, because you have to make sure these strings are kept up-to-date whenever you rename anything. What’s worse is that because reflection is late-bound, you aren’t aware of the problems until the code is actually executed, so this renaming could introduce hidden bugs that don’t appear until runtime. With the growing popularity of refactoring techniques, it’s becoming more important that we can use reflection without having to worry about this problem.

It’s very true that tools like Resharper can certainly help with refactoring reflection-based code, but none of them are perfect and they only help the people that use them.

In C# 3 we were introduced to lambda expressions and Linq, and with them came the Func<> and Expression<> classes; these are the key to static reflection. The Func<> set of classes allow you to use lambda expressions that return a value, while an Expression<> can be used to programatically access the contents of a delegate.

Combining Func<> and Expression<> can give us a very powerful way to statically retrieve PropertyInfo (and similar) instances from a lambda expression. For example Expression<Func<Customer, object>> represents an expression that contains a delegate that returns a value (of type object), with a Customer parameter; I’ll illustrate:

// method to receive an expression
public PropertyInfo GetProperty<TEntity>(Expression<Func<TEntity, object>> expression)

// usage
GetProperty<Customer>(customer => customer.Name);

What this is actually doing is creating a lambda that returns a value, the value of customer.Name in this case. Here’s the trick, we don’t actually care about the value that’s returned! In-fact, we don’t even evaluate this expression at all.

The reason we use object in the Func signature, rather than a more specific type, is because we want to allow any property to be used; however, if you were only interested in string properties, then you could restrict it by replacing this parameter.

The Expression API itself is very in-depth, so I won’t go into the intricacies of it but here’s a very simple implementation of static reflection.

public PropertyInfo GetProperty<TEntity>(Expression<Func<TEntity, object>> expression)
{
  var memberExpression = expression.Body as MemberExpression;

  if (memberExpression == null)
    throw new InvalidOperationException("Not a member access.");

  return memberExpression.Member as PropertyInfo; // Should account for FieldInfo too
}

Stepping through this code, we start by getting the body of the expression which we cast to a MemberExpression; this is us grabbing the customer.Name part of our expression. Now we can get the member itself and cast it to a PropertyInfo, this is the Name part of the expression body. That’s it! We’ve not evaluated the expression, but we’ve inspected it and retrieved the property.

This example is for illustrative purposes, there are many different types of expressions which would be excluded by this. If you are to implement your own static reflection parser, you should cater for these other types of expressions.

As this example shows, we’re able to use reflection without having to resort to strings. The great thing about this is that if you change the name of a member inside a lambda, you’ll get a compile error if you haven’t updated all the references! No more hidden bugs.

So that’s how the magic behind Fluent NHibernate (and others) works, simple when you know how!

The problem was incorrectly stated. There isn’t a lack of OSS projects that VB programmers can use, there’s a wealth of projects out there. I’ve personally used IoC containers, ORM tools, unit testing tools, and build automation tools in VB with my most recent employer. The issue is that more recent projects are using some language features of C# that the VB team hasn’t chose to implement. This has got Roy all up in arms because he feels that should be our problem (as the OSS developers).

On a side note, it was also mentioned that there are few VB OSS developers because they don’t have anything to cut their teeth on. Chicken and the egg, no VB OSS projects means no VB OSS developers.

The fact that there are plenty of OSS projects out there that VBers can use kinda makes the argument that VB developers don’t contribute to OSS because they don’t have anything to start with redundant; the whole chicken and the egg argument is flawed because OSS is already out there. It has been out there for years and yet there are still precious little contributions from VB developers.

I think it all stems from a funny situation we’ve got ourselves into, one of unfounded expectations. C# and VB have always been pretty much the same language, just with different syntax. Everything you could do in C# you could do in VB. That’s no longer the case from .Net 3.5 onwards; however, it was only ever the case by coincidence due to their base in the CLI. If the CLI was never involved, they’d never have travelled the same path. When you take a step back and look at them for what they are, two completely distinct languages, this expectation for crossover appears less reasonable. I wouldn’t expect a Ruby developer to complain that they can’t use my C# project, so why should a VBer complain? VB is just as different a language as Ruby is to C#.

• If you want a framework for Ruby, you’d pick a Ruby framework.
• If you want a framework for C#, you’d pick a C# framework.
• So why if you want a framework for VB, do you pick a C# framework?

Regarding the conversation…

To those VB developers who responded with conspiracy: there is no conspiracy. Nobody is developing with C# out of spite, we do it because it’s our preferred language; nobody would accuse you of being spiteful if you chose to develop in VB, so don’t accuse us of doing it.

To those VB developers that think we choose C# because it’s the “flavour of the week” versus the old workhorse of VB: that just shows how far behind you really are; if you genuinely believe the C# developers think it is en-vogue, then you’re sorely mistaken. I don’t think I know any C# developers that actually think C# is really awesome, just that it’s their preferred of the two .Net languages.

I can’t believe I fell for a C# vs. VB argument.

As a part of a project I’m working on I needed a simple file to store some data in, and I didn’t want it to be XML (for no reason other than the verbosity). I could have used my own format, but instead I’ve gone for YAML. If you’ve worked with Ruby on Rails at all, then you’ll be familiar with YAML. It’s a human readable (and writable) text format.

Of course, I still needed to be able to parse my YAML document. There was a project announced 2 years ago to create a .Net parser, but like many things, it seems very much abandoned. So, after my recent adventure with OMeta#, I thought I’d hack on this too.

Introducing YaYAML: Yet another YAML parser.

Don’t get your hopes up, I’ve only implemented exactly what I needed out of the spec, which is very little indeed. However, it’s something I will carry on with when time permits. So what can you parse with YaYAML? Only documents containing a single flat sequence or mapping. No nesting, no multiple documents in a file, no variables.

It’s possible to parse these two example files:

- a list
- of text
- strings

a: mapping
of: various
key: and
value: pairs

That’s it!

You can find the source in my YaYAML github repository.

Update:
I’ve since added support for sequences of maps, so this is supported too:

- name: James
  age: 23
- name: Peter
  age: 34

String parsing is hard. I don’t think anyone will deny that. You can parse it by hand, you can use regular expressions, you can walk it character by character. With SharpDiff, I needed to parse some serious text, it was in an expected format, but there are numerous rules surrounding it. I did not fancy parsing it by hand, or with regular expressions.

I considered writing a parser for it, but dismissed that after my dealings with ANTLR in BooLangStudio. It’s not so much that ANTLR is bad, it’s just long winded; it’s completely visitortastic.

Anyway, after 10 minutes down the path of parsing it myself, I cracked and decided to look into alternatives to ANTLR. I came across OMeta# and (with a reassuring nudge by Jeffery Olson) I went with it.

So what is OMeta#?

At it’s heart, OMeta is just a really great string parser, and OMeta# is a .Net implementation of it. Combine that with a fairly decent definition language and codegen’d parser creation, and you’re onto a winner.

It allows you to write a syntax grammar and parse content with it, without having to worry about lexing, tokenizing and all that jazz. You only need to learn one language, OMeta.

While working on SharpDiff, I took a detour and implemented another very simple Git diff format. It’s a stat/metrics diff that just tells you which files have changed, and how many additions and removals have occurred in each. A pretty straight forward diff crying out to be used as an example.

A basic OMeta-based parser

Git has a diff format called stat (and it’s counter-part numstat, that we’ll be using). It produces output like so:

1    0    myFile.txt
3    1    anotherFile.txt

If you’re following along at home, you’ll need to create yourself a new git repository. In there place a couple of text files, add some content to them and commit them. Then make some changes to those files, but don’t commit that. Now you can execute git --numstat to get the above output.

The Git documentation is a wonderful thing, and it provides us with a nice outline of the numstat output.

1    2    README
3    1    arch/{i386 => x86}/Makefile

That is, from left to right:

1. the number of added lines;
2. a tab;
3. the number of deleted lines;
4. a tab;
5. pathname (possibly with rename/copy information);
6. a newline.

Before we get to the meat, there’s a couple of things we need to do. Firstly, (at the time of writing) there are no binaries available for OMeta#, so you’ll have to download the source and compile yourself. Once you’ve done that, you need to reference the OMetaSharp.dll and OMetaSharp.OMetaCS.dll.

Due to OMeta codegening our parser, it really needs to be built separately to our main project. If we don’t do that, we could get ourselves in a mess when we write an invalid grammar and generate some uncompiling code from it.

I won’t go over how to do this, but basically wrap the following code in a separate console app, changing the paths to point to where your code actually lives.

public void RebuildGitNumstatParser()
{
  var contents = File.ReadAllText(@"..\..\..\SharpDiff\Parsers\GitNumstatParser.ometacs");
  var result = Grammars.ParseGrammarThenOptimizeThenTranslate
    <OMetaParser, OMetaOptimizer, OMetaTranslator>
    (contents,
     p => p.Grammar,
     o => o.OptimizeGrammar,
     t => t.Trans);

  File.WriteAllText(@"..\..\..\SharpDiff\Parsers\GitNumstatParser.cs", result);
}

That just gets OMeta to compile our grammar, then spit out a C# file.

One more thing, then we can get going. For this generation to work, we really need to give it a grammar and parser to begin with. So we’ll create an empty grammar and parser.

using OMetaSharp;

ometa GitNumstatParser : Parser {
}

public class GitNumstatParser : Parser
{
}

Now we can begin! One of the wonderful things about OMeta# is that it can be test driven very easily, which really surprised me.

So lets create our first test!

[Test]
public void ParsesNumber()
{
    var result = Parse<int>("1", x => x.Number);

    Assert.That(result, Is.EqualTo(1));
}

In this test, we pass the Parse function a generic type parameter (int) which is our expected return type, then a string and an expression. The string is our input content, and the expression is the grammar rule to use for parsing.

I’m also using a shortcut method for parsing, which you can see below:

protected T Parse<T>(string text, Func<GitNumstatParser, Rule<char>> ruleFetcher)
{
    return Grammars.ParseWith(text, ruleFetcher).As<T>();
}

When you run this test, it should pass. We didn’t do anything, I hear you say. That’s because we didn’t have to in this case. OMeta# comes with a few predefined rules that you can sometimes take advantage of (or override to give different meaning in your grammar). In this case, we’ve used the Number rule, which parses a string and returns an integer from it.

Onto the next test.

[Test]
public void ParsesAdditionsAndSubtractionValues()
{
    var result = Parse<FileStats>("3\t8\tmyFile.txt\r\n", x => x.Number);

    Assert.That(result.Additions, Is.EqualTo(3));
    Assert.That(result.Subtractions, Is.EqualTo(8));
}

We need a class to represent our file statistics, I’ve created one called FileStats.

public class FileStats
{
  public FileStats(int additions, int subtractions)
  {
    Additions = additions;
    Subtractions = subtractions;
  }

  public int Additions { get; private set; }
  public int Subtractions { get; private set; }
}

When you run this test, it will fail (and at the time of writing, fail with a nasty unhelpful OMeta exception). This is because we’re still trying to use the Number rule, so we need to create our FileStats rule.

Open up your ometacs file and follow along.

using SharpDiff.FileStructure.Numstat;
using OMetaSharp;

ometa GitNumstatParser : Parser {
  FileStats = Number:adds '\t' Number:subs
    -> { new FileStats(adds.As<int>(), subs.As<int>()) }
}

Right, that’s a bit of an overload, so lets go through it.

The line is made up from three parts:

1. Rule name
2. Pattern to match
3. Code to produce

For this line, we’re creating a rule called FileStats, which matches the Number:adds '\t' Number:subs pattern, and produces the code new FileStats(adds.As<int>(), subs.As<int>()).

Lets examine what the pattern is doing. Firstly, we’re using the Number rule that we used in our first test. The colon denotes an assignment to a variable, so we’re getting the match from the Number rule and putting that in an adds variable. We then match a single tab character (‘\t’), and then another Number. Whitespace is ignored in the OMeta grammar, which means you can structure the file pretty much however you like.

Our pattern gives us two variables, adds and subs, we need to do something with them. The -> operator designates the next curly brace surrounded region to be your desired C# code output. For this rule, we’re creating a new instance of our FileStats class, and passing our two variables into the constructor (converting them to ints at the same time).

At this point, run your side executable that recreates the generated parser. You should now be able to alter your test to use the FileStats rule instead of Number, and have it pass.

So what can we parse now? We’re able to get the additions and subtractions from a line such as 1 4 myFile.txt.

We still need to be able to get the filename back though, so onto our next test.

[Test]
public void ParsesFilename()
{
  var result = Parse<string>("anotherFile.txt", x => x.Filename);

  Assert.That(result, Is.EqualTo("anotherFile.txt"));
}

This test won’t compile until we create our Filename rule, so off to the ometacs with us!

using SharpDiff.FileStructure.Numstat;
using OMetaSharp;

ometa GitNumstatParser : Parser {
  FileStats = Number:adds '\t' Number:subs
    -> { new FileStats(adds.As<int>(), subs.As<int>()) },
  Filename = LetterOrDigit+:name '.' LetterOrDigit+:ext
    -> { name.As<string>() + "." + ext.As<string>() }
}

We’ve now got an extra rule at the end of the file, Filename. I can’t stress this enough, watch your commas; OMeta#s errors are poor, and something like that can trip you up.

Our new rule looks complex, but is pretty simple. It uses the built-in LetterOrDigit rule, which matches a single letter or digit. We suffix that call with a + which (like regex) matches one or more instances; that match is then stored in a name variable. Following that is a single full-stop. Finally, another LetterOrDigit+, which matches our extension. We then concatenate those strings in our C# output.

Again, recompile your parser. Now your test should pass. It simply matches any filename with an extension (room for improvement here!).

Now we can bring the two together, so we can parse a whole line. Next test!

[Test]
public void ParsesFullFileLine()
{
  var result = Parse<FileStats>("3\t8\tmyFile.txt\r\n", x => x.FileStats);

  Assert.That(result.Additions, Is.EqualTo(3));
  Assert.That(result.Subtractions, Is.EqualTo(8));
  Assert.That(result.Filename, Is.EqualTo("myFile.txt"));
}

We need to update our FileStats class so it supports the filename.

public class FileStats
{
  public FileStats(int additions, int subtractions, string filename)
  {
    Additions = additions;
    Subtractions = subtractions;
    Filename = filename;
  }

  public int Additions { get; private set; }
  public int Subtractions { get; private set; }
  public string Filename { get; private set; }
}

Our grammar file is going to undergo a bit of refactoring too. We’re covered by tests, so why shouldn’t we? Our FileStats rule doesn’t really describe the whole line it should be matching. Really what we should have is a LineStats (that’s what our FileStats currently is) that just matches the numbers, then a FileStats that matches the numbers and the filename.

ometa GitNumstatParser : Parser {
  FileStats = LineStats:lines '\t' Filename:name NewLine
    -> { new FileStats(
      lines[0].As<int>(),
      lines[1].As<int>(),
      name.As<string>()) },
  LineStats = Number:adds '\t' Number:subs
    -> { adds, subs },
  Filename = LetterOrDigit+:name '.' LetterOrDigit+:ext
    -> { name.As<string>() + "." + ext.As<string>() },
  NewLine = '\r' '\n'
}

So what we’ve done here is redo our FileStats rule as LineStats, which instead of creating an instance of the FileStats class, just returns an array of it’s two matches { adds, subs }; this encapsulates that particular bit of behavior. Next we’ve created our new FileStats rule, which calls our LineStats rule and captures the matches. It then matches a single tab, and the filename using our Filename rule, followed by a NewLine; these are then combined and pushed into the constructor for our FileStats class. We’ve defined NewLine at the end, and it simply matches the \r\n characters.

Rebuilding and running that test should now give success. We’re now able to completely parse a diff line. Only one thing left to do, parse multiple lines together.

[Test]
public void CanParseMultipleLines()
{
  var result = ParseList<FileStats>(
    "3\t8\tfile.txt\r\n" +
    "5\t1\tanotherFile.txt\r\n", x => x.FullFile);

  Assert.That(result.Count, Is.EqualTo(2));
  Assert.That(result[0].Filename, Is.EqualTo("file.txt"));
  Assert.That(result[0].Additions, Is.EqualTo(3));
  Assert.That(result[0].Subtractions, Is.EqualTo(8));
  Assert.That(result[1].Filename, Is.EqualTo("anotherFile.txt"));
  Assert.That(result[1].Additions, Is.EqualTo(5));
  Assert.That(result[1].Subtractions, Is.EqualTo(1));
}

Our final test is a bit longer than the others, but it’s simple. We pass in some multiline input, and then assert that we have two FileStat objects, and that they’re correctly formed.

For this test we’re using another helper method, which returns a list of rule matches.

protected IList<T> ParseList<T>(string text, Func<GitNumstatParser, Rule<char>> ruleFetcher)
{
  return new List<T>(Grammars.ParseWith(text, ruleFetcher).ToIEnumerable<T>());
}

Again, this test will fail because we haven’t defined the FullFile rule. So again to the ometacs file.

FullFile = FileStats+:files -> { files },

All we do this time is add this rule to the top, which uses the + operator to match multiple FileStats rules. They’re then returned as they are so we can convert them to an enumerable.

That’s it, recompile and run, you should now be parsing full diff outputs with ease!

As you can see OMeta# is pretty easy, and it’s very easy to test drive. There are a few quirks to doing it that way (such as having to create the compiled grammar before your test will run), but it’s a lot smoother than I expected. The grammars are quite simple too, and there are some shortcuts you can take which help make things easier. The SharpDiff grammar currently stands at just 49 lines, and it’s capable of parsing 90% of the standard git output, not bad!

I’ll just introduce you to another little bit of syntax that can make things simpler. Our Filename rule matches filenames with extensions, but it doesn’t match filenames without! That could be a problem; however, instead of creating a new rule for this, you can create multiple patterns for a rule. Each pattern will get evaluated if the one before it fails.

So we can update our Filename rule to the following, which tries to match a filename with an extension, and if it can’t do that, it then tries without an extension.

Filename = LetterOrDigit+:name '.' LetterOrDigit+:ext
  -> { name.As<string>() + "." + ext.As<string>() }
         | LetterOrDigit+:name
  -> { name.As<string>() },

SharpDiff is a library for parsing the output of various diffing tools. It’s primary purpose is to reduce the time spent by SCM UI developers in handing diff output.

Why SharpDiff

I’ve got a few tools in mind that require parsing of diff files. I figure it’s a pretty common thing for SCM UI developers to have to do, so I thought i’d put it out for others to use.

Parsing your first diff

The implementation is not concrete yet, but the current (easiest) way to parse a diff file is as follows.

string diffContent = File.ReadAllText("MyDiffFile.diff");

Diff diff = Diff.CreateFrom(diffContent);

From there you have a compiled version of your diff document. Intellisense will be your friend here, but basically you have a Chunks collection, and a Files collection.

The Wikipedia article on Diffs is worth a read if you’re interested. In short though, chunks are formed as a chunk header containing the affected lines, and the lines themselves.

@@ -1,3 +1,6 @@
This is a small text file
+that I quite like,
 with a few lines of text
-inside, nothing much.

The chunk header is @@ -1,3 +1,6 @@. The -1,3 describes the affected lines in the original file, the first number (ignoring the minus) is the start line, and the second number is the total of context lines plus subtraction lines. The second range (+1,6) is in the new file, and that starts on the first line, and has six affected lines; in this case it’s all the context lines plus all addition lines.

All the other lines are the actual changes themselves. A line prefixed with a + is an addition line, a line prefixed with a – is a subtraction line, and lines prefixed with a space are context lines. Context lines are used for aligning the changes in the document. They’re also useful for determining if the document has changed since the diff was created.

In the context of SharpDiff, your Chunks collection contains an instance of a Chunk for every part in the diff that resembles the above. Each chunk has the range info for the original and new file, and a Lines collection of each line.

Early Days

WARNING: SharpDiff is still in early development. I wouldn’t recommend using it in production code yet, as the parser is severely limited, and there’s next to no error handling.

The biggest flaw is that it only supports the standard git-diff output, and doesn’t handle many special circumstances.

It does support:

• Standard git-diff header
• Index extended header
• Chunk header
• Chunk lines (added, removed, and contextual)
• No newline at end of file
• Multiple chunks per diff
• Multiple diff per input string

It doesn’t support:

• Other extended headers
• Formats other than git-diff

Example

As quick example of what you could use this library for, here’s a screenshot of a git-diff application:

Get Involved

You can find the source on my github account, in the sharpdiff repository.

If you’re interested in helping with SharpDiff, then let me know. All comments, suggestions, and contributions are welcome. Feel free to contact me either through github, or my e-mail.

When you’re implementing a custom language in Visual Studio, there’s a very good chance that you’re going to want to handle indentation slightly differently to the defaults. Every language has it’s own rules, after all.

Most of the resources I found online we’re pretty poor for how to get this working. Most people we’re pointing to overriding OnCommand in your derived Source class, or implementing some interop interface (i.e. IVsLanguageLineIndent). I could get none of these working. OnCommand never got raised, and the interfaces we’re useless.

I tried a few different methods for handling indentation, but none of them worked very well. I tried capturing the enter key press, but that didn’t work. Then I tried capturing alterations to the document, but those also got fired for navigating the document, so you’d press the up key and add a new line!

It ended up being pretty simple to implement, once I finally found the correct way to do it. I’ll cover how I did this for BooLangStudio below.

In your LanguageService, there’s a method you can override called CreateViewFilter which sets everything in motion.

Create yourself a class that derives from ViewFilter, and then return an instance of it from the overridden CreateViewFilter method in your language service.

Note: You need to make sure your project is configured to use Smart Indentation. If your project is complete enough to allow the user to customise this, then you’re fine. However, if not you can hard code this value yourself. In your language service there’s a GetLanguagePreferences method that returns all the preferences for your project. In that method you can set languagePreferences.IndentStyle = IdentingStyle.Smart, which is what I’ve done in BooLangStudio.

You’ll kick yourself for how easy this is. Now override the HandleSmartIndent method in your derived ViewFilter. That’s it really, in there you can access the Source object and do as you wish with smart indentation.

Taking BooLangStudio as an example, you can see in our BooViewFilter.cs that I delegate the work to a HandleSmartIndentAction. This is to make testing easier by having as little dependencies on Visual Studio as possible.

The Execute method of our HandleSmartIndentAction.cs class gets the caret location and passes it to an instance of a LineIndenter class, which determines (based on the previous line to the caret) whether the next line should be indented, or outdented.

So that’s how to implement Smart Indentation in your Visual Studio Extensibility project, and a little bit of implementation details of BooLangStudio.

Console.WriteLine("Start...")

var originalColour = Console.ForegroundColor;
Console.ForegroundColour = ConsoleColor.Red;

Console.WriteLine("WARNING!");

Console.ForegroundColour = originalColour;

It’s not too bad when you’re only doing it once, but when you start swapping colours all over the place, then it can become very noisy. So this is where my class comes into play. Using the same syntax I described in my previous post, I’ve wrapped up the colour changing in a helper method that takes an Action delegate. This allows you to write much more intention revealing code.

ConsoleColours.Foreground(ConsoleColor.Yellow, () =>
{
  Console.WriteLine("Different text");
});

I find this much cleaner and the blocks gives my console code some much needed separation.

Here’s the full class code:

public class ConsoleColours
{
  public static void Foreground(ConsoleColor colour, Action action)
  {
    var original = Console.ForegroundColor;
    Console.ForegroundColor = colour;

    action();

    Console.ForegroundColor = original;
  }

  public static void Background(ConsoleColor colour, Action action)
  {
    var original = Console.BackgroundColor;
    Console.BackgroundColor = colour;

    action();

    Console.BackgroundColor = original;
  }
}

The “traditional” usage of the using statement can be found quite often in the land of files and streams. Take the following example, which opens a file and then closes it when it drops out of the using scope.

using (var stream = File.OpenRead("myFile.txt"))
{
  // do something with the file
}

Examples of the alternative usage can be found all over the place, but Rhino Mocks is one that’s close to my heart. Here’s from the record/replay syntax, anything in the scope of the using is recorded, and once it drops out of scope it’s no longer in record mode.

using (mocks.Record())
{
  Expect.Call(customer.Address)
    .Return("123 Rester St");
}

Again, I do like what the using statement gives us outside of releasing resources (I’m not disputing it’s usefulness there). However, I think the using keyword itself adds noise and clouds intention.

With the adoption of 3.5, I’ve started using an alternative syntax instead of usings. Actions and anonymous methods to the rescue.

Scope(() =>
{
  // do something within this scope
});

It’s a little bit more noisy in the compiler satisfying department, but because you have full control over naming, you can reveal intention more. No more unclear “using”.

So how does it work? Simple really, the method takes an Action delegate, which it the executes almost immediately. I say almost, because you can execute code before and after the execution. That gives you the benefits of the using statements wrapping ability.

public void Scope(Action action)
{
  // do something before
  action();
  // do something after
}

Some more examples:

File.OpenRead("myFile.txt", file =>
{
  // do something with the file
});

mocks.Record(() =>
{
  Expect.Call(customer.Address)
    .Return("123 Rester St");
});

I prefer this syntax over the using statement. Of course, it’s only valid for 3.5 projects.