Когда использовать DebuggerDisplayAttribute


Каковы некоторые рекомендации по использованию атрибутаDebuggerDisplayAttribute ? Что определяет ваши решения о том, когда и как применять атрибут к вашему коду? Например..

  1. считаете ли вы DebuggerDisplayAttribute более полезным для некоторых типов объектов (т. е. пользовательских структур данных), чем для других?
  2. вы определяете его по открытым типам, внутренним типам или обоим?
  3. вы обычно добавляете его в начальную реализацию или ждете, пока тестер/пользователь запросит его?
  4. когда это лучше определить DebuggerDisplayAttribute , а когда имеет смысл переопределить .ToString()?
  5. есть ли у вас рекомендации по количеству данных, которые вы предоставляете в атрибуте, или ограничения на объем вычислений для включения?
  6. применяются ли какие-либо правила наследования, которые сделали бы более выгодным применение к базовым классам?
  7. Есть ли еще что-нибудь, что следует учитывать при принятии решения о том, когда и как его использовать?
4 5

4 ответа:

Это субъективно, и я бы не решился сказать, что есть какие-то лучшие практики, но:

  1. Считаете ли вы DebuggerDisplayAttribute более полезным для некоторых типов объектов (т. е. пользовательских структур данных), чем для других?

На сегодняшний день наиболее часто используются типы, представляющие бизнес - объекты, и я обычно буду отображать ID + name. Также любые типы, которые будут храниться в коллекциях в приложении.

Кроме этого, я добавляю его всякий раз, когда нахожу себя часто выполняется поиск свойств в отладчике.

2.Do вы определяете его по открытым типам, внутренним типам или обоим?

Оба.

3.Вы обычно добавляете его в начальную реализацию или ждете, пока тестер/пользователь запросит его?

Тестеры / пользователи никогда не увидят его - он используется только во время отладки.

4.Когда лучше определять атрибута debuggerdisplayattribute и когда он делает больше смысла, чтобы переопределить .Метод toString()?

Переопределение ToString (), когда требуется представление во время выполнения, либо для ведения журнала, либо для конкретных приложений. Используйте DebuggerDisplayAttribute, если он нужен только для отладки.

5.Do у вас есть рекомендации по количеству данных, которые вы предоставляете в атрибуте, или ограничения на объем вычислений для включения?

Поскольку он не используется во время выполнения, единственное ограничение заключается в том, что он должен быть достаточно быстрым, чтобы не препятствовать отладке (особенно при многократном вызове элементов коллекции).

Вам не нужно беспокоиться о раскрытии конфиденциальных данных, как это было бы с журналированием времени выполнения (например, путем переопределения .ToString), потому что такие данные все равно будут видны в отладчике.

6.Do применяются ли какие-либо правила наследования, которые сделали бы более выгодным применение к базовым классам?

Нет, примените его к классам, которые вам нужны.

7.Is есть что-нибудь еще, чтобы рассмотреть когда вы решаете, когда и как его использовать?

Больше я ничего не могу придумать.

Я часто использую его, когда знаю, что раздел кода потребует много отладки. Это экономит некоторое время при просмотре объектов в отладчике, особенно если вы используете выражения типа "{ChildCollection.Count}". Это дает вам быстрое представление о данных, которые вы смотрите.

Я почти всегда ставлю его на класс, который в конечном итоге окажется в коллекциях, так что он действительно быстро видит каждый элемент, а не просто кучу MyNamespace.Элементы MyClass, которые вы должны расширить.

Мое мнение таково, что ToString() используется для представления данных конечным пользователем. DebuggerDisplay предназначен для разработчиков, вы можете решить, чтобы показать идентификатор элемента, некоторые дополнительные внутренние / частные свойства.

Забавно, что вы должны спросить, JaredPar совсем недавно сделал очень хороший пост в блоге под названиемDebuggerDisplay attribute best practices .

DebuggerDisplay имеет значение для любого класса, который не имеет значимой реализации .ToString(), но я лично не видел, чтобы кто-то активно писал атрибуты, пока они не понадобятся.

В целом, ссылка Омера на лучшие практики выглядит как здравый совет; однако я лично отклонился бы от предложения иметь специальный метод DebuggerDisplay() - даже если он частный, он, кажется, дает мало преимуществ по сравнению с атрибутом, кроме удаления магических строк.