type MyVector(x:int, y:int, z:int) =
        // expose the values as an array
        member this.Values = [| x; y; z |]

    let v = new MyVector(1,2,3)
    v.Values.[0] <- 42
    printfn "%d" v.Values.[0]

It prints “1”.  To see why, let’s look at the corresponding C# code, in all its verbosity:

    class MyVector
    {
        int x, y, z;
        public MyVector(int x, int y, int z)
        {
            this.x = x;
            this.y = y;
            this.z = z;
        }
        // expose the values as an array
        public int[] Values
        {
            get { return new[] { x, y, z }; }
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            var v = new MyVector(1, 2, 3);
            v.Values[0] = 42;
            System.Console.WriteLine(v.Values[0]);
        }
    }

The C# code, being more explicit, makes things a little more obvious.  “Values” is a getter property, whose body creates a new array, and so every time you refer to “.Values”, a fresh array is created that contains the 3 integers that were passed into the constructor.  So the line that assigns the value 42 assigns it into a fresh array that is then immediately dropped on the floor.

This probably isn’t what is desired.  If we want “Values” to expose a single instance of a mutable array, then we can easily do so, by creating that array instance in the class constructor and returning that same instance each time people refer to the property.  In C#:

    class MyVector
    {
        int[] a;
        public MyVector(int x, int y, int z)
        {
            this.a = new[] { x, y, z };
        }
        // expose the values as an array
        public int[] Values
        {
            get { return a; }
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            var v = new MyVector(1, 2, 3);
            v.Values[0] = 42;
            System.Console.WriteLine(v.Values[0]);
        }
    }

and in F#:

    type MyVector(x:int, y:int, z:int) =
        let a = [| x; y; z |]
        // expose the values as an array
        member this.Values = a

    let v = new MyVector(1,2,3)
    v.Values.[0] <- 42
    printfn "%d" v.Values.[0]

I see people occasionally stumble on this in a variety of ways; the fact that F# property getter syntax (and overall syntax) is so succinct makes it easier to forget that the body of the member is code that will run each time the member is referenced.  One-time initialization should be moved to the constructor (the let/do section prior to the members; see this blog for a primer on the F# class/interface syntax).

Every language has its own little gotchas; at work those on the C# team still fall into the trap described here, and so it is fun to josh each other about the minor warts in our respective languages.  :)

Since I dislike code-free blogs, I’ll leave you with a quick code snippet.  Ask yourself, what does this code print?  (Then try it.)

    type MyVector(x:int, y:int, z:int) =
        // expose the values as an array
        member this.Values = [| x; y; z |]

    let v = new MyVector(1,2,3)
    v.Values.[0] <- 42
    printfn "%d" v.Values.[0]

A hint: it illustrates a “gotcha” people sometimes hit when first learning the syntax for writing F# property getters.

type SomeType() =

     member this.Foo(x:int, s:string) = 
         printfn "%d: %s" x s

and you type “///” anywhere on the blank line before “Foo”, then you get

type SomeType() =
     /// <summary>
     /// 
     /// </summary>
     /// <param name="x"></param>
     /// <param name="s"></param>
     member this.Foo(x:int, s:string) = 
         printfn "%d: %s" x s

with your cursor sitting conveniently between the summary tags.  And if instead you type “///” above the type declaration, you get

/// <summary>
/// 
/// </summary>
type SomeType() =

     member this.Foo(x:int, s:string) = 
         printfn "%d: %s" x s

Get the idea?  Just type “///” on a blank line right before a member, type, or module-scoped let (before any attributes, if there are any), and you get a blank xmldoc template (if there wasn’t already an xmldoc there).

I don’t plan to put this one on the gallery, as I’m not too interested in maintaining it.  You can grab the the source from github, set the VSIX project as the startup project, and build it yourself.  (If someone is interested in refining/publishing it, you can contact me directly.) 

The source code is simple, and structured just like my previous extension.  There are two projects. “MyFSParser” is (again) just the parser code ripped from the F# compiler, with about 130 new lines of code at the end of MyParsing.fs that computes information about every xml-doc-able entity in a file.  “FSXmlDocVSIX” is the editor extension that, in a mere 120 lines of code in Program.fs, intercepts keypresses and does some special logic when you press ‘/’ to see if you just typed “///” on a blank line above an xml-doc-able, and if so, dumps extra stuff into your editor buffer.  It’s really simple; if you ever wanted to look at a straightforward extension to the Visual Studio editor, this is a good code sample.

Here’s a quick overview of what’s there.  There is a Visual Studio 2010 solution with two projects. 

• The “MyFSParser” project is a library that parses F# source code and yields “range” information about where source code constructs begin and end.  It is basically a free-standing version of the front half of the F# compiler, followed by about 350 lines of my own code for munging and publishing range information from the abstract syntax tree (AST) produced by the F# compiler front end.
• The “VSIXColorizer” project is a Visual Studio extension that plug into the editor, listens for changes in the test buffer, re-parses the source, gets the range information, tags editor ‘spans’ with the semantic depth information, and then draws adornments on the screen for the portions of the file in view.  It’s also about 350 lines of code.

Of course all the code is written in F#.  This is a nice sample that demonstrates both the simple Visual Studio extensibility model that makes it easy to craft editor extensions, as well as the kinds of things you can do when you leverage the F# compiler source to do the “heavy lifting” to parse F# code for you.

In order to provide a little more guidance, I made a couple screencasts, about 10 minutes each, where I give a (rambling) walkthrough of each of the projects.  You won’t learn all the fine details about how the compiler code or my code works, but you will get an overview of the structure and see some of the important methods/functions and how the pieces fit together.  Here is the video about the parser and here is the video about the colorizer.

I’ve already started working on another editor extension that reuses the parser library code, and so in another week or two hopefully I’ll share that too.  I hope this is good “seed code” to help you leverage the F# compiler source and Visual Studio extensibility to do your own cool stuff!

Oh, that was me.  :)

Like I said in the previous blog, I don’t have the skills to design a good GUI to edit the colors or figure out the most discoverable place in VS to edit them.  But maybe you do!  And so in the spirit of sharing source, here’s a crummy (but working) standalone app for experimenting with the colors.  A screenshot is suggestive:

Basically, you can click on one of the rectangles, and then use the buttons to change the R/G/B values of the left-edge color or the main color.  And once you have colors you like, you can click a different button which prints out a .reg file you can use to install those colors.  (The app only reads the registry, it does not write it, so you have to copy-paste the text from the console window, save it to a .reg file, and run it if you want to install your updated colors.)

Anyway, the code is below.  Just throw this in an F# Console Application, add references to the WPF assemblies (PresentationCore, PresentationFramework, System.Xaml, System.Xml, UIAutomationTypes, and WindowsBase), press Ctrl-F5 to build and run and you’re off to the races.  Feel free to steal all this code to build your own better app/extension, or just to use to build your own attractive color schemes.  The code is just a quick ugly hack, but hopefully you can work with it.

And yes, I’ll be releasing the code for the actual editor colorizer extension soon, I just want to finish tidying it up a little.  (Thanks to those who have already left feedback and pointed out minor bugs!)

Quickie code for app to manage editing colors:

open System.Windows
open System.Windows.Controls
open System.Windows.Data
open System.Windows.Media
open System.Windows.Shapes
open Microsoft.Win32 

type IIndexable<'a> =
    abstract member Item : int -> 'a

let makeBinding(sourceObj:obj, sourcePath:string, converter:'T->'U,
                targetObj:DependencyObject, targetDependencyProperty:DependencyProperty) =
    let b = new System.Windows.Data.Binding()
    b.Source <- sourceObj
    b.Path <- new System.Windows.PropertyPath(sourcePath)
    b.Converter <- 
        { new System.Windows.Data.IValueConverter with
            member this.Convert(v, targetType, param, culInfo) =
                box(converter (unbox v))
            member this.ConvertBack(v, targetType, param, culInfo) =
                raise <| new System.NotImplementedException() }
    BindingOperations.SetBinding(targetObj, targetDependencyProperty, b) |> ignore

type MyWindow() as this =
    inherit Window()

    static let selectedRectangleNumber = 
        DependencyProperty.Register("SelectedRectangleNumber", typeof<int>, typeof<MyWindow>,
            new FrameworkPropertyMetadata(0, FrameworkPropertyMetadataOptions.AffectsRender,
                new PropertyChangedCallback(fun depObj ea -> 
                    match box depObj, box ea.NewValue with 
                    | (:? MyWindow as w), (:? int as x) -> w.TriggerSelectedRectangleNumberChanged(x)
                    | _ -> ())))

    let selectedChanged = new Event<Handler<int>,int>()
    let getNum() = this.GetValue(MyWindow.SelectedRectangleNumber) :?> int
    let setNum(n) = this.SetValue(MyWindow.SelectedRectangleNumber, n)

    let colors =
        try
            let key = Registry.CurrentUser.OpenSubKey(
                @"Software\Microsoft\VisualStudio\10.0\Text Editor\FSharpDepthColorizer")
            Array.init 10 (fun i -> key.GetValue(sprintf "Depth%d" i) :?> string)
            |> Array.map (fun s -> let [|r1;g1;b1;r2;g2;b2|] = s.Split[|','|] |> Array.map byte
                                   r1,g1,b1,r2,g2,b2)
        with e ->
            [|  // greyscale colors
            190uy,190uy,190uy,230uy,230uy,230uy
            170uy,170uy,170uy,210uy,210uy,210uy
            184uy,184uy,184uy,224uy,224uy,224uy
            164uy,164uy,164uy,204uy,204uy,204uy
            178uy,178uy,178uy,218uy,218uy,218uy
            158uy,158uy,158uy,198uy,198uy,198uy
            172uy,172uy,172uy,212uy,212uy,212uy
            152uy,152uy,152uy,192uy,192uy,192uy
            166uy,166uy,166uy,206uy,206uy,206uy
            146uy,146uy,146uy,186uy,186uy,186uy
            |]
    // why the SolidColorBrush below? 
    // to have a DependencyObject to data-bind... there is probably a cleaner way, but oh well
    let edgeColors = colors |> Array.map (fun (r,g,b,_,_,_) -> SolidColorBrush(Color.FromRgb(r,g,b)))
    let mainColors = colors |> Array.map (fun (_,_,_,r,g,b) -> SolidColorBrush(Color.FromRgb(r,g,b)))
    let brushes = 
        let makeGradientStop(b:SolidColorBrush, pct) =
            let gs = new GradientStop(b.Color, pct)
            makeBinding(b, "Color", (fun (c:Color) -> c), gs, GradientStop.ColorProperty)
            gs
        { new IIndexable<Brush> with 
            member this.Item depth =
                upcast new LinearGradientBrush(
                    new GradientStopCollection(
                        [|
                        makeGradientStop(edgeColors.[depth], 0.0)
                        makeGradientStop(mainColors.[depth], 0.01)
                        makeGradientStop(mainColors.[depth], 1.0)
                        |] ), new Point(0.0, 0.5), new Point(1.0, 0.5)) }

    let printCurrentSettings() =
        printfn "Windows Registry Editor Version 5.00"
        printfn ""
        printfn "[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Text Editor\FSharpDepthColorizer]"
        for i in 0..9 do
            let ec = edgeColors.[i].Color
            let mc = mainColors.[i].Color
            printfn "\"Depth%d\"=\"%d,%d,%d,%d,%d,%d\"" i ec.R ec.G ec.B mc.R mc.G mc.B 

    let mkButton(colors:SolidColorBrush[], text, dr, dg, db) =
        let b = new Button()
        b.Content <- text
        b.Click.Add(fun _ -> colors.[getNum()].Color <- 
                                Color.FromRgb(colors.[getNum()].Color.R + byte dr,
                                              colors.[getNum()].Color.G + byte dg,
                                              colors.[getNum()].Color.B + byte db))
        b

    let mkButtonPanel(colors:SolidColorBrush[],text,dr,dg,db,f) =
        let panel = new StackPanel(Orientation = Orientation.Horizontal)
        let tb = new TextBlock()
        selectedChanged.Publish.Add(fun _ ->
            makeBinding(colors.[getNum()], "Color", (fun (c:Color) -> f(c).ToString()),
                        tb, System.Windows.Controls.TextBlock.TextProperty))
        panel.Children.Add(mkButton(colors, text+" down",-dr,-dg,-db)) |> ignore
        panel.Children.Add(tb) |> ignore
        panel.Children.Add(mkButton(colors, text+" up",dr,dg,db)) |> ignore
        panel

    do
        let leftPanel = new StackPanel(Orientation = Orientation.Vertical)
        leftPanel.Children.Add(mkButtonPanel(edgeColors,"edge R",2,0,0,(fun c->c.R))) |> ignore
        leftPanel.Children.Add(mkButtonPanel(edgeColors,"edge G",0,2,0,(fun c->c.G))) |> ignore
        leftPanel.Children.Add(mkButtonPanel(edgeColors,"edge B",0,0,2,(fun c->c.B))) |> ignore
        leftPanel.Children.Add(mkButtonPanel(mainColors,"main R",2,0,0,(fun c->c.R))) |> ignore
        leftPanel.Children.Add(mkButtonPanel(mainColors,"main G",0,2,0,(fun c->c.G))) |> ignore
        leftPanel.Children.Add(mkButtonPanel(mainColors,"main B",0,0,2,(fun c->c.B))) |> ignore
        let printButton = new Button(Content="Print current settings to console")
        printButton.Click.Add(fun _ -> printCurrentSettings())
        leftPanel.Children.Add(printButton) |> ignore
        let mainPanel = new StackPanel(Orientation = Orientation.Horizontal)
        mainPanel.Children.Add(leftPanel) |> ignore
        let canvas = new Canvas()
        for i in 0..mainColors.Length-1 do
            let rect = new Rectangle(Width=600., Height=500., Fill = brushes.[i])
            rect.MouseDown.Add(fun _ -> setNum(i))
            Canvas.SetLeft(rect, (float i)*30.)
            Canvas.SetTop(rect, (float i)*30.)
            Canvas.SetZIndex(rect, i)
            canvas.Children.Add(rect) |> ignore
        let rect = new Rectangle(Width=600., Height=40.)
        selectedChanged.Publish.Add(fun _ -> rect.Fill <- brushes.[getNum()])
        Canvas.SetLeft(rect, 0.)
        Canvas.SetTop(rect, (float mainColors.Length)*30. + 20.)
        Canvas.SetZIndex(rect, mainColors.Length)
        canvas.Children.Add(rect) |> ignore
        mainPanel.Children.Add(canvas) |> ignore
        this.Content <- mainPanel

    member private this.TriggerSelectedRectangleNumberChanged(x:int) = selectedChanged.Trigger(this, x)
    static member SelectedRectangleNumber = selectedRectangleNumber 

[<System.STAThread>]
do
    (new Application()).Run(MyWindow()) |> ignore

Once installed, the structure of your code will be highlighted in the editor, like this

or like this

rather than plain old code like this

Get the idea?  As suggested by the first two screenshots, the colors are configurable.  A good UI for configuring the colors was beyond me, so the colors are configurable via a registry setting.  (EDIT: see also here) If you don’t have the registry entry, you get the “greyscale” colors from the first screenshot by default.  Those greyscale colors could be represented via the following registry entry:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Text Editor\FSharpDepthColorizer]
"Depth0"="190,190,190,230,230,230"
"Depth1"="170,170,170,210,210,210"
"Depth2"="184,184,184,224,224,224"
"Depth3"="164,164,164,204,204,204"
"Depth4"="178,178,178,218,218,218"
"Depth5"="158,158,158,198,198,198"
"Depth6"="172,172,172,212,212,212"
"Depth7"="152,152,152,192,192,192"
"Depth8"="166,166,166,206,206,206"
"Depth9"="146,146,146,186,186,186"

Alternatively, the red-blue colors from the second screenshot are:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Text Editor\FSharpDepthColorizer]
"Depth0"="240,180,180,240,220,220"
"Depth1"="180,180,240,220,220,240"
"Depth2"="240,172,172,240,216,212"
"Depth3"="172,172,240,212,216,240"
"Depth4"="240,164,164,240,212,204"
"Depth5"="164,164,240,204,212,240"
"Depth6"="240,156,156,240,208,196"
"Depth7"="156,156,240,196,208,240"
"Depth8"="240,148,148,240,204,188"
"Depth9"="148,148,240,188,204,240"

and more generally, the extension will look for the those registry keys.  (You can save these registry examples to a file “foo.reg” and then run the “foo.reg” file to install those keys, or use the “regedit” tool to inspect/change the values.  Be careful when modifying your registry!)

The DepthN values are strings of six numbers, representing two sets of RGB values, e.g.

DepthN = R1, G1, B1, R2, G2, B2

where N is the depth of the nesting of the source code structure, the RGB1 values are the color of the left edge of the highlight (intention is to provide more visual contrast at the edge), and the RGB2 values are the main color for highlighting that nesting depth.  There must be 10 depths, if you go deeper, the tool cycles around:

where the colors are getting darker until it’s gone 10 deep and cycles back around to using the lightest pink color from that color set.

I’ll publish the source code for this VSIX extension soon. (EDIT: It’s posted, see here.)   For now, I’d encourage you to try it out; you can leave feedback on my blog or on the gallery.  Enjoy!

(Much thanks to Noah who helped me write the editor portion of the extension.  Thanks to many people who did beta testing and offered useful feedback.)

The basic idea is an editor extension that uses background colorization to show the “control flow depth” of F# code.  A screenshot is a little suggestive:

but in order to really describe it, I made a video (about 6 minutes long), linked below.

The idea is simple; the F# compiler code already knows how to do all the heavy lifting of parsing source code and creating a parse tree (an abstract syntax tree, or “AST”), and the AST knows all the info about code structure and e.g. that this expression starts in this line/column and ends in this other line/column.  So I just take the tree and turn it into some useful “depth and span” information, which I then use from a Visual Studio editor extension to add color adornments in the editor.

This is still under development, but I plan to publish the extension on the Visual Studio Gallery, and publish the source code when I’m done.

Anyway, check out the video here.  I’m interested to hear what people think, and hope this inspires others to try their hand at leveraging the F# compiler code to write cool tools and extensions.

Don’s F# talk entitled “The Future of F#: Data and Services at your Finger Tips” is scheduled during the final timeslot on Friday afternoon, so of course readers of this blog will want to check that out.  Windows Phone 7 will be another hot topic at PDC; I have been trying really hard to get my hands on a phone, so that I can show off some F# apps running on the phone at the Experts table, but so far I’ve only met dead ends.  I’ve still got another 36 hours or so, and I haven’t given up on that yet. 

Regarding general F# news… I recently saw F# get some love on HackerNews, and PDC will be sure to generate some more F# buzz this week.  And I think perhaps there’s some more F# news in store soon after PDC as well.  So now is a good time to have your finger on the pulse of the F# community; Planet F# or Rick Minerich’s blog are good ways to keep up with the F# highlights.  On the other hand, if you’re relatively new to the world of F#, you might prefer reading Getting started with F#.

In completely unrelated news, I recently posted an answer to Best explanation for Languages without Null on StackOverflow that has easily become my highest-upvoted-answer ever.  Undoubtedly the large bounty on the question helped attract eyeballs… regardless of why, I’m pleased that my thoughts on this topic garnered so much attention.  (It makes up at least a tiny bit for my lack of substantive blogging of late; this is my fifth post in a row that’s light on code or novel ideas.  I hope to have some meatier/code-ful topics to blog about soon.)

Enough rambling for now – enjoy PDC this week!

open System
open System.Numerics

let maxIteration = 100

let modSquared (c : Complex) = c.Real * c.Real + c.Imaginary * c.Imaginary

type MandelbrotResult =
    | DidNotEscape
    | Escaped of int

let mandelbrot c =
    let rec mandelbrotInner z iterations =
        if(modSquared z >= 4.0)
            then Escaped iterations
        elif iterations = maxIteration
            then DidNotEscape
        else mandelbrotInner ((z * z) + c) (iterations + 1)
    mandelbrotInner c 0

let chars = " .:-;!/>)|&IH%*#"

for y in [-1.2..0.05..1.2] do
    for x in [-2.0..0.025..0.9] do
        match mandelbrot(Complex(x, y)) with
        | DidNotEscape -> Console.Write " "
        | Escaped i -> Console.Write chars.[i &&& 15]
    Console.WriteLine() 

The Javascript-ful site, in addition to just nicely colorizing the F# code as above, also provides hover tooltips in your browser, much like you’d get from Visual Studio.  On the cloned blog entry you can hover over the identifier “maxIteration” and see that it is an “int”, for example.  It’s very cool.

(By the way, yes, the Mandelbrot code I stole mercilessly from Luke’s recent timely blog.)

Anyway, Tomas’ tool is so cool I had to immediately try it out in a blog post before I went to sleep tonight.  Here’s the output of the program, by the way:

With PDC coming soon, one imagines there may be other exciting F#-related announcements coming soon as well!

One of the best features of Visual Studio is Intellisense, the auto-completion that suggests legal completions when you “dot into” an object, and brings up a list of identifier completions when you press a keyboard shortcut like Ctrl-Space.  This kind of auto-completion is one of those most-addictive productivity features, where once you’ve used it, you can’t imagine how you ever lived without it.  Nowadays I think most every IDE supports this feature in one way or another.

The Intellisense for F# that we shipped as part of VS2010 is pretty great; I use (read: “depend on”) it all the time.  Nevertheless, there are a number of corner cases where the completion lists fall down, and pressing “dot” yields incomplete or incorrect information.  On the F# product team, we refer to these cases as “bugs”.  :)

Red

I’ve recently been spending time fixing these Intellisense bugs.  The associated product code is the F# Language Service; a “language service” in Visual Studio is the code that provides all the logic for editor support of a given programming language: features like syntax coloring, Intellisense, “Go To Definition”, etc.

So I start looking at these bugs and spelunking through the language service, and guess what – most of it is code I have either (1) never looked at or (2) completely forgotten.  Before I can fix anything, I’ll need to understand how it all works!

Fortunately, much of this code was originally authored by my esteemed colleague Jomo Fisher.  Among Jomo’s many admirable developer qualities: he is a TDD-er and avid unit tester.  I had started doing a little TDD and unit testing on my own before joining the F# team, but then I joined F# and saw the foundation Jomo had laid for unit-testing the F# language service, and I started to really learn about unit testing.  The Visual Studio architecture is all about interfaces and services, which means you can mock out all of your VS dependencies and create tests against your VS language service that don’t require Visual Studio to be running.  And that’s what Jomo had already established when I first joined the team – a bunch of NUnit tests against the F# language service he was authoring.

Fast-forward two-and-a-half years, to earlier this week when I wanted to fix an Intellisense bug.  Step one, of course, is to author the tests.  I had a few repros in hand of places where Intellisense fails (uncovered by some reliability tests written by Jack (a tester on F#) and inspired by Dmitry (another developer on F#)), so I authored a few small test cases to put the bugs under test.   I’m now a one-third the way through the TDD mantra “red, green, refactor!”  The next step it harder, though.

Green

Now I need to try to fix the bug.  Only I haven’t the faintest idea where to start, since I don’t know or recall any of this code.  So I fire up the Visual Studio debugger and start stepping through the code.  The debugger is a good tool for code understanding – when coupled with good unit tests, it is fantastic.  Stepping through the code, setting interesting breakpoints, and inspecting call-stacks helped me understand how the various components and functions related to one another.  Debugging individual unit tests (where each test is effectively a specification of a tiny feature) helped me identify which pieces of code were attached to which individual features.  I probably spent about 4 hours meandering through perhaps some 7000 lines of code, learning how it fit together and locating likely places I would need to eventually make some fixes.

So I finally start making changes and try to make one of my newly-created red tests turn green.  Make a change, run that test.  Hurrah, it turns green!  Now, run the other 600 language service tests.  :)  And of course, I’ve broken like 50 of those.  Great, my unit tests are fulfilling one of their purposes – preventing me from regressing existing functionality.  Once again I pop open the debugger, and step through a test I just broke, to understand how what-I-just-changed interacted with this old test.  Here, a good debugger really shines.  I see it going past some code I just changed, and now because of the computations I just changed, I think it’s now going into this “else” branch, whereas previously I suspect it was going down the “if” branch.  Well, I could back out my change, and re-compile, and re-debug, and see if it does take the other branch and if that’s the key difference between red and green for this test.  But hey, I’m in the Visual Studio debugger, so I can poke at the live program state however I like.  So once I reach the “else”, I drag the little yellow arrow (the ‘next statement’ icon in the margin) up into the “if” to “Set Next Statement” as though the if condition were true rather than false, and then press F5 to keep going.  And sure enough, now the test is green again.  So I’ve quickly verified my hypothesis about “what changed” inside the debugger, without having to recompile the program.  Alternatively, I could poke new values into variables in the “locals” window as another way to test hypotheses about changes without having to actually change and recompile the program.  It takes a few minutes to recompile these components and re-install the newly-compiled components, so it really is time-saving (as well as keeping you engaged/focused) to do this hypothesis-testing quickly inside the debugger without needing a recompile.

Ok, so now I think I grok how my change interacted with and broke existing tests, so I’m ready to try a different fix.  I make a change, recompile, and while it’s compiling I speculate about which tests I expect to turn green and which I think will stay red.  Re-run some tests and continue to hone my understanding.  The test I’m looking at, incidentally, is when you type

    [1..System.

you don’t get Intellisense, even though e.g.

    [1..System.Int32.MaxValue]

is a legal eventual completion.  Debugging… ok, I’ve definitely found a bug in a function called “QuickParse”, which parses the current line of text where you pressed dot and tries to find The.Qualified.Identifier that appears just to the left of the dot you’re pressing.  It would typically return a list of dot-separated identifiers, like [“The”;”Qualified”;”Identifier”], but in the case above, it has something like [“1”;””;”System”].  QuickParse doesn’t know about the range operator (..) and so it thinks all those bits are part of a qualified identifier, with e.g. the empty identifier “” as the “namespace between the two dots” of the range operator, rather than understanding “System” as being the start of the current identifier.  Indeed, if you do

    [1 .. System.

with a space after the range operator, then you do get Intellisense again, as QuickParse correctly handles that case.  Ok, so I can fix this.  Eventually after a number of iterations of this kind of work, I have my new tests turning green, and only 4 existing tests red, and all of those involve Intellisense of Obsolete entities.  I debug through those tests, and find the special logic for Obsolete-handling, and just above that code I discover a comment in the code that basically says “here we rely on the fact that we get an empty identifier in certain cases…” aha!  The “bug” in QuickParse is actually a “feature” used by this other code. 

Now maybe if I had found that code/comment sooner, it would have saved me a couple hours of debugging.  But it would have cost me all the code understanding I gained during the debugging session.  I have a number of Intellisense reliability issues to fix, as well as some new feature work in the area ahead of me, so it is very much worthwhile for me to get a deep understanding of how everything here works, so that I have this all “cached into my brain” for my next few weeks of work.

Anyway, that “feature” of QuickParse and the nearby code is a rather subtle and ugly to my eye, so now it’s time to…

Refactor

In the course of my investigation, I’ve already found a few cleanups that don’t break any tests, and so I can move the code in the general direction I want it to go, even if I’m not all done fixing things yet.  Our suite of unit tests gives me the confidence to make changes to this “code I’d never seen prior to a couple days ago”.  (My own manual testing inside Visual Studio, getting a code review approved, and having the QA group poking at the product, all also inspire more confidence that regressions will be discovered, but the unit tests provide the most immediate feedback that things are ok.)

I don’t yet have a tidy end to this fixing-an-Intellisense-bug story, as I’ve brought you up to date now (right now I understand the issue, but haven’t fixed the bug and got all the tests green yet).  But that’s ok, because this particular narrative is just a means to an end, a way to describe how unit tests and debugging lead to understanding of code.  So let me wrap up.

Summary

When you have good unit tests, everything is better; if you’re already a TDD-er, then  saying that is just preaching to the choir.  And when you have a good debugger, using that tool is a great way to learn about an unfamiliar code base (stepping through code, setting breakpoints, looking at stacks, changing values of locals or the next statement to see how things react).  Put those two together, and the effect is even more powerful.  Unit tests + debugger = code understanding!