Editor's note: The following post was written by Visual Studio ALM MVP Richard Banks

Viewing your code through Visual Studio’s CodeLens

We’ve seen it all when it comes to code, right? Good code, bad code, code with tests, code without tests, clean code, spaghetti code and code that makes you scratch your head and wonder just what someone was thinking when they wrote it.

Wouldn’t it be nice if Visual Studio let you know if code was unit tested or not? What if it could let you know a change was going to break large amounts of other code? What if it could give you the back story on why a particularly nasty piece of code turned out the way it has?

Enter Visual Studio 2013’s new CodeLens; a tool to help you answer all those questions.

CodeLens is a like window into your code, a lens if you will, showing you what you cannot see when just looking at the code on your screen. Think of it like your car’s dashboard, giving you unobtrusive, at your fingertips, information as you drive your IDE. Never more than a glance away.

To show you why this is such a brilliant feature let’s ask some typical developer questions and see how CodeLens helps us answer them. By the end you should have a good understanding as to why CodeLens is such an invaluable addition to Visual Studio 2013 and a must-have feature.

“If I change this code, what might I break?”

You want to make a change to some code, however you’re uncertain what else will be affected if you do or if you’ll end up chasing the ripples of your change throughout your entire code base. It’s important to know the answer as it affects the size of the work in front of you.

With CodeLens you can quickly see an incoming reference count for the code you’re looking to alter and can quickly assess the first stage impact of any change.

To give you an example of CodeLens in action we’re going to use the excellent RestSharp open source project. Here we see the CodeLens dashboard showing us that the IRestClient interface has 54 references to it:

Clicking the reference count opens the CodeLens window showing all the places where references exist in the solution. Hovering over a reference will show a small code snippet of the calling code giving you more context when needed.

It’s not just types that this applies to, either. The same behavior applies to methods and properties as well.

As you might expect, double clicking a reference will navigate you to the referring code. From a usability perspective, when you double click a reference in the popup to navigate to a reference the popup will close. What if you wanted to keep those references handy so you could look at a number of them individually? Clicking the dock icon in the top right of the popup will close the popup and add it as a docked window so that the information remains available for you as you navigate through your code.

What if you want to get a feel for how far a change might spread? Looking at just the first level of references is OK, you can use the Show on Code Map link to visualize all the incoming code connections at once.

From an understanding perspective, if you double click a node in the code map you will navigate to the calling method. If you then open the references indicator for the caller and click the Show on Code Map link, its own references will be added to the code map allowing you to rapidly build up a great visualization of how far a change might spread. How good is that!

“If I change this, will it still work? How can I be sure?”

Those of you following a test driven approach to development may have already answered this question with “Because the tests will break!”

While that might be true for some of us, many of us live with test suites that are, well, “limited” in terms of what they cover. Making the question harder to answer is that without easily seeing what the tests we have actually call it’s hard to know if the code you want to change is executed by a unit test or not.

CodeLens helps answer that question by showing a count of tests (as discovered by the Test Explorer) that reference your methods along with their current success status.

In this example there are two tests calling the ExecuteAsync method, with the tests yet to be run. Clicking Run All will run the displayed tests, not all the tests in the solution, allowing you to just run the tests that are impacted by your change. Of course, once those tests are passing you should then do a full test run prior to checking in your code.

When a test run finishes, CodeLens will show the updated results. Here I’ve deliberately broken a test so you can see the different success statuses:

Wonderful! No more excuses, people. Write those tests!

“Am I looking at the latest code?”

Ever looked at a method, made some changes to it and then realised it wasn’t the most recent code you changed? Yeah, me too.

CodeLens helps you answer the latest code question by asynchronously querying Team Foundation Server when it loads its indicators. It checks if there are more recent changesets on the server than what you’re working on and will show you when this is the case.

To activate this feature your code will need to be in a TFS 2013 team project using Team Foundation Version Control. The CodeLens indicator will look as follows:

The indicator 6+1 changes is showing there is a changeset on the server more recent than my local workspace. Clicking the indicator will show the list of changes including the author and when they were made.

In this case we also see the IronProgrammer has linked their changeset to a work item, providing even more context about their change and further aiding understanding.

“Why is this code like it is?”

Being able to see the changes for a piece of code along with related work items and code reviews provides fantastic context in determining how code came to be as it currently is. If that information isn’t enough for you, you can double click any of the items to be taken to the relevant TFS entities for even more detail.

If your organization uses Lync you also have the ability to open a Lync conversation with the changeset author, directly from the CodeLens window. It takes the guess work out of why a change was made and fosters improved communications in the development team.

“Is this code healthy?”

Finally, while it’s not part of the default CodeLens experience, the CodeLens team have released an experimental extension you might want to try out.

It shows a maintainability index for your code; a rating of the health of what you’re looking at, and how that maintainability has changed over time. Perfect for staying on top of your technical debt!

You can find it on the Visual Studio Gallery by searching for ‘Code Health Indicator’.

Being an experimental indicator means the team is trying out some ideas. It’s not a supported extension and it may well change in functionality over time, but don’t let that put you off. Try it out and provide some feedback and suggestions. I’m sure they’d welcome it.

Wrapping Up

CodeLens loads its indicators asynchronously so you shouldn’t feel any performance impact in daily use. Of course, Visual Studio gives you great control of your development experience so if you can disable CodeLens if you want to. You can also restrict it to display a subset of indicators and you can change the font and color of the dashboard text. It’s completely up to you.

So there you have it, a quick look at Visual Studio 2013’s new CodeLens feature. I think it’s a fantastic addition and should be part of every developer’s .NET toolbox! I hope you enjoy it.

About the author

Richard Banks is a Microsoft Visual Studio ALM MVP, Professional Scrum Trainer for Scrum.org, author of the Visual Studio 2012 Cookbook and runs the Sydney Alt.Net user group. For some strange reason he gets a real kick out of helping development teams improve their skills and produce great software. You can get in touch with him on twitter at @rbanks54 and follow his blog at http://www.richard-banks.org/.  He currently works as a Principal Consultant for Readify.