Display of search results in Visual Studio has been remarkably primitive despite numerous improvements in other areas. Eclipse, in contrast has added some compelling features such as clustered results grouped by packages and classes and the ability to prune results. Now, simplicity has its place, sometimes the simple list of text makes it easier to scan.

Previously, I described how to retrieve search results programmatically. Here, I show a proof-of-concept on how to customize the look and feel of search results in Visual Studio:

I’ve written a proof-of-concept visual studio extension that will highlight search results that you have visited. Unlike other customization attempts that modify registry settings to shorten file paths, here, we can actually change the visual tree.

Here’s how I did it:

First, get the search results window as a IWpfTextView.

// Get search results window 1
IVsUIShell shell = (IVsUIShell)this.GetService(typeof(SVsUIShell));
Guid windowGuid = new Guid(EnvDTE.Constants.vsWindowKindFindResults1);
IVsWindowFrame windowFrame = null;
shell.FindToolWindow((uint)__VSFINDTOOLWIN.FTW_fFindFirst, ref windowGuid, out windowFrame);

// Get Document
object view;
windowFrame.GetProperty((int)__VSFPROPID.VSFPROPID_DocView, out view);

//Get WPF Version of view;
IComponentModel componentModel = this.GetService(typeof(SComponentModel)) as IComponentModel;
var factory = componentModel.GetService<IVsEditorAdaptersFactoryService>();
var wpfView = factory.GetWpfTextView(view as IVsTextView);

// Listen to double click events
if (wpfView != null)
{
   var viz = wpfView.VisualElement as Control;
   if (viz != null)
   {
       viz.MouseDoubleClick += delegate(object sender, MouseButtonEventArgs e)
       {
           var me = sender as IWpfTextView;
           new ExperimentalAdornment(me);
       };
   }
}

“Those who cannot remember the past are condemned to repeat it”

By now this is a cliché saying, but does history really have any relevance in software development?

In preparing for writing a research statement and job talks, I’ve been thinking about an unifying theme of research. One question become clear: Why and what would you use recorded history of software development for? It was a question asked by my advisor as a challenge, and at the time I had many doubts that there were any useful purposes that could be found. For example, I thought why do we even have version control besides the purposes of code integration and backups. How many N versions do we ever look back on a project in practice? Sure, maybe you’re supporting different versions of the product and that’s useful to you, but is the actual history relevant to a typical developer with the same intensity as an archeologist cherishing an ancient Mayan pottery fragment?

Similarly, in our world we do not see the construction of the Eiffel Tower or the chisels on a statue, but only what is present now. What can we learn from looking at the history that we cannot gain from just looking at the code itself?

Some answers:

Did we make an impact?

Did our research or tool make an impact? For example, we looked at whether developers choose to use a refactoring tool or manual text manipulation to refactor a program. Turns out, the developer’s we studied used refactoring tools for less than 10% of refactorings. We’re now asking the similar question about the impact of java generics.

How do developers really work?

With more detailed history, we can ask more about how developers work. I started off with simple questions: how many files and methods do developers work with in a day), i.e. what is the mental workload? Further, how well can we predict what these would be (i.e. building a recommendation tool)? Next, I looked at work sessions in detail. How long are developers working in a day, are they frequently interrupted? This was interesting because it was one of the first research demonstrating how fragmented and broken a developer’s day is and what they do to try to recover.

Viewing source code differences is something programmers do almost daily. Yet, how we view diffs is little changed since some of the first tools came out in the 1970s. Sure, techincal improvements have been made (accounting for whitespace, word-level diffs, providing more context, structural diffs).

But for the most part, tools either dump out plain text, or provide a side-by-side view of two colorized text files, in typically hideous color schemes. Thumbnail views are a nice touch. Overall, these views are great for detailed tasks when doing a merge or making absolute sure a character was not inadvertently mangled. All said, they are terribly verbose and sluggish for more casual tasks such as to check up on recent code changes team members made, or reminding yourself of recent changes you’ve when you were last working on a task.

Here are some approaches I’ve been tinkering with that can provide some alternative ways of working with diffs:

Diff Maps

Want an overview of a changeset? The diff map displays all the affected source files and overlays the changes over those files. It focuses on changes, making other non-changed code smaller. This gives you an idea of where a changeset occurred throughout the system. This is a variation of the pixel-line visualization of files (seesoft view).

Change Episodes

Want a timeline of changes? Something that would let you mentally walk back in time, help you resume an interrupted task? Change episodes are created from local history (edits have timestamps) and reconstructed in the order you made the edit. This lets you see the changes as they happened and help restore your thoughts and trigger any reminders about code (oh, I still need to fix that!).

Rethinking typography

Most diff tools either change the foreground or background color to indicate modifications. Unfortunately, this tends to clash with our normal experience with viewing code – mainly syntax highlighting, but the highlighted colors can also be harder to read. What are some other ways to emphasize that a change occurred? Further, can we do more than color?