Scott Wegner
Scott Wegner

Reputation: 7473

When to use DebuggerDisplayAttribute

What are some best practices around the DebuggerDisplayAttribute? What guides your decisions on when and how to apply the attribute to your code? For example..

  1. Do you find DebuggerDisplayAttribute more useful on some types of objects (i.e. custom data structures) rather than others?
  2. Do you define it on public types, internal types, or both?
  3. Will you generally add it to the initial implementation, or wait for a tester/user to request it?
  4. When is it better to define DebuggerDisplayAttribute and when does it make more sense to override .ToString()?
  5. Do you have guidelines on how much data you expose in the attribute, or limits on the amount of computation to include?
  6. Do any inheritance rules apply that would make it more beneficial to apply on base classes?
  7. Is there anything else to consider when deciding when or how to use it?

Upvotes: 9

Views: 3353

Answers (4)

gurkan
gurkan

Reputation: 1480

Debugging mode without DebuggerDisplay Attribute

Without the attr

Debugging mode with DebuggerDisplay Attribute

With the attr

[DebuggerDisplay("{Name,nq}")]//nq suffix means no quotes 
public class Product {

    public int Id { get; set; }

    public string Name { get; set; }

    //Other members of Northwind.Product
}

DebuggerDisplay attribute best practices

Tell the debugger what to show using the DebuggerDisplay Attribute (C#, Visual Basic, F#, C++/CLI)

Debugger/Diagnostics Tips & Tricks in Visual Studio 2019

Although the attribute is quite old, you should watch the applause and the narrator's reaction :) By the way, if you want to see more debugger tricks, you might want to see this demo at your free time.

Upvotes: 7

STW
STW

Reputation: 46366

DebuggerDisplay has value for any class which doesn't have a meaningful .ToString() implementation, but I personally haven't seen anyone proactively write the attributes until they are needed.

In general, Omer's link to best practices looks like sound advice; however I personally would lean away from the suggestion to have a dedicated DebuggerDisplay() method--even though it's private it seems to offer little benefit over the attribute aside from removing magic strings.

Upvotes: -1

to StackOverflow
to StackOverflow

Reputation: 124686

It's subjective and I'd hesitate to say there are any best practices, but:

  1. Do you find DebuggerDisplayAttribute more useful on some types of objects (i.e. custom data structures) rather than others?

By far the most common use is types that represent business entities - and I'll commonly display ID + name. Also any types that will be stored in collections in the application.

Other than that I add it whenever I find myself frequently searching for properties in the debugger.

2.Do you define it on public types, internal types, or both?

Both.

3.Will you generally add it to the initial implementation, or wait for a tester/user to request it?

Testers/users won't ever see it - it's only used while debugging.

4.When is it better to define DebuggerDisplayAttribute and when does it make more sense to override .ToString()?

Override ToString() when you want the representation at runtime, either for logging or application-specific purposes. Use DebuggerDisplayAttribute if you only need it for debugging.

5.Do you have guidelines on how much data you expose in the attribute, or limits on the amount of computation to include?

As it's not used at runtime, the only constraint is that it should be fast enough not to impede the debugging experience (especially when called multiple times for elements of a collection).

You don't need to be concerned about exposing sensitive data as you would with runtime logging (e.g. by overriding .ToString), because such data will be visible anyway in the debugger.

6.Do any inheritance rules apply that would make it more beneficial to apply on base classes?

No, apply it on the classes you need it.

7.Is there anything else to consider when deciding when or how to use it?

Nothing else I can think of.

Upvotes: 10

Johann Blais
Johann Blais

Reputation: 9469

I use it a lot when I know that a code section will require a lot of debugging. It saves some time when browsing the objects in the debugger, especially if you are using expressions like "{ChildCollection.Count}". It gives you a quick idea of the data you are looking at.

I almost always put it on class that will end up in collections so that it is really quick to see each item and not just a bunch of MyNamespace.MyClass elements that you have to expand.

My opinion is that ToString() is used to provide an end-user representation of the data. DebuggerDisplay is for developers, you can decide to show the element ID, some additional internal/private properties.

Upvotes: 2

Related Questions