Thursday, 7 December 2017

Format Specifiers in Visual Studio Debugger (using C#)

Below are the few format specifiers developers can use while debugging the applications which can help reducing debugging time by certain clicks/expansions (in a Watch window). 
I have tested these code samples using Visual Studio 2017 Community Edition.

1. ac


Often working with LINQ queries, we try to evaluate the expression/query into watch window and on upon stepping through the lines we may need to check the result for the same query and click on small refresh button to get the updated value. That is going to be tedious work if we need to keep evaluating the same for lengthy code. Well, there is a way to avoid that. Using format specifiers (while debugging), you can force the evaluation of the expression.


For example, consider below code, demo class containing ID and the name properties. I have decorated class with DebuggerDisplay attribute to view the elements in watch window. For more details, please visit my article on the same here.

[DebuggerDisplay("{ID}:{Name}")]
public class DemoClass
{
    public int ID { getset; }
    public string Name { getset; }
 
}

Inside the main method, I am populating the list of the DemoClass objects.

List<DemoClass> lstDemoClasses = new List<DemoClass>();
for (int i = 0; i < 5; i++)
{
    lstDemoClasses.Add(new DemoClass { ID = i, Name = $"name {i}" });
}
var somequery = lstDemoClasses.Where(obj => obj.ID % 3 == 0).ToList();
 
lstDemoClasses.Add(new DemoClass { ID = 100, Name = "name 100" });
Console.WriteLine();


Consider that you have some query (dummy query) where you want to list the objects whose ID is divisible by 3. And at the same time, you want to list the objects whose ID is even. For the same, I am adding the lambda query in my watch window like this.


Watch Window:



Now the moment I step through the breakpoint above, it is going to add one more object to the collection and query in watch window not going to be evaluated as shown in watch window. In order to evaluate query, one may need to hit that little refresh button and then it would work. For the most cases, it is okay to hit and go back to debugging but with couple of queries together it would be little time consuming.





To avoid these clicks, you can use the format specifiers for the watch window. For example, to force the evaluation of expression in watch window, you can specify ac separated by comma in Name column as below.












So now, when you step through the breakpoint (where it adds an object to collection with id as 100), debugger forces the evaluation of the query in watch window and you don’t need to hit refresh button.

2. results

Another format  specifier comes handy when you need to view the complex queries in watch window that holds list/collection.
For example, below is the sample code for the same. I have list of strings and I am creating dynamic object that holds the list of names with their length (where length of the name is greater than 4).

List<string> names = new List<string>()
{
    "str 1",
    "string 2",
    "test string 3",
    "test string 4121"
};
var linqQuery = names.Where(nm => nm.Length > 4).Select(obj => new
{
    id = obj.Length,
    names = obj
});
Without any specifier, watch window looks something like below:



By default, it shows some of the private variables from this dynamic object and you can change this behavior if you are focused on the results view only. Using results specifier, you would only see the result/collection directly. You can skip the in between privates and avoid one click while debugging.



3. nq


Using this specifier, you can view the string without quotes (no quotes). It is kind of least useful but I thought to mention it here, just in case.



There are few more specifiers you can go through the same here.

Please feel free to comment the suggestion(s) to make it better.



No comments:

Post a Comment