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

Question

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

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

Answer 1

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

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

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

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

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

Оба.

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

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

4. Когда лучше определить DebuggerDisplayAttribute и когдаимеет ли смысл переопределять .ToString ()?

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

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

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

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

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

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

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

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

Answer 2

Забавно, что вы должны спросить, JaredPar недавно сделал очень хороший пост в блоге под названием Рекомендации по использованию атрибута DebuggerDisplay .

Answer 3

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

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

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

Answer 4

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

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