Easier Debugging with DebuggerDisplay

Debugging is probably not the part you look forward to most. You’ve got your breakpoint set, the debugger’s up and running, and boom—you’re staring at a giant object with a dozen properties that mean nothing without digging through each one. Wouldn’t it be nice if you could customize what you see in that debugging window? Well, .NET has you covered with the DebuggerDisplay attribute.

What is `DebuggerDisplay`?

The DebuggerDisplay attribute is like a customizable label for your classes when you’re debugging. By adding it, you can control what shows up in the debugger when you hover over your objects, making the whole experience way more intuitive.

Without DebuggerDisplay, you’re at the mercy of whatever .NET thinks is the best string representation of your object, which is usually just the type name. But with it, you can show whatever properties you want in whatever format you like.

Example time!

Let’s say you’ve got a simple Person class:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
}

Now, if you were to instantiate this and hover over it in the debugger, you’d see something like:

namespace.Person

Not super helpful, right? You’d have to expand the object to see the details you really want.

By adding DebuggerDisplay, you can change this:

[DebuggerDisplay("Name = {FirstName} {LastName}, Age = {Age}")]
public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
}

Now, when you hover over a Person instance in your debugger, it’ll show:

Name = John Doe, Age = 30

Explanation

The DebuggerDisplay attribute is added just above your class definition. The string you pass in is an expression that’ll be evaluated in the context of your class. Any properties, fields, or even methods that return a value can be used inside curly braces {}. Here’s a breakdown of the syntax:

Plain Text: Anything outside the curly braces will be displayed as-is.
Expressions: Anything inside {} will be evaluated at runtime.
Method Calls: You can even call methods, but be careful about performance and side effects!

For example:

[DebuggerDisplay("Full Name = {GetFullName()}, Age = {Age}")]
public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }

    public string GetFullName() => $"{FirstName} {LastName}";
}

This will display the result of GetFullName() along with the age in the debugger. Just remember that calling a method might have performance implications if you’re dealing with a large number of objects.

Common Pitfalls

Don’t Use Methods with Side Effects: Calling methods in DebuggerDisplay is okay as long as they don’t change the state of your object. If a method modifies data or has side effects, you’ll be in for some weird debugging sessions.
Be Careful with null Values: If your properties can be null, make sure your DebuggerDisplay handles that gracefully to avoid runtime exceptions while debugging.
Avoid Complex Logic: Keep it simple! DebuggerDisplay is evaluated every time you view an object in the debugger, so it should be quick and not alter the state of your object.

Conclusion

The DebuggerDisplay attribute is one of those small things that can make a big difference when debugging. It makes your objects way more readable in the debugger and can save you a lot of time.

Remember, the goal is to make your debugging experience more intuitive without sacrificing performance or introducing potential bugs. So add those attributes, and hope it makes debugging a little better!

Affiliate promo

If you love learning new stuff and want to support me, consider buying a course from Dometrain using this link: Browse courses – Dometrain. Thank you!

Coding Bolt