DebuggerDisplay #решение

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

При этом, можно пойти немного дальше, и подумать о тех, кто наш код будет отлаживать. Например, взаимодействовать с нашим классом. Например, это будет наш класс User, инстансы которого мы перебираем в foreach или сложили в массив.

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

[DebuggerDisplay("{Name} ({Email})")]
public class User {
    public string Email;
    public string Name;
}

Эта штука работает, как в VS, так и в Rider. Коллегам не нужно будет углубляться в подробности свойств класса, они сразу увидят в отладчике то самое, что им хотелось бы знать об инстансе конкретного класса.

Я употребляю слово "класс", но на самом деле аттрибут можно применить и для структур. И использовать не только свойства, но и результаты методов, которые возвращают string.

Мне кажется, что подобный аттрибут должен быть у всех наших библиотечных классов, а также у Dbo и Dto, имеющих человекочитаемые названия. Гораздо проще посмотреть сет данных глазами и найти всё то, что нам нужно.

P.S.: Задали логичный вопрос, почему бы просто не использовать метод ToString. Мне кажется, что мы путаем тёплое с мягким.

1. Вспоминаем принцип единой ответственности.
2. И получается, что DebuggerDisplay создан для случаев отладки, а не для случаев преобразования объекта в строку. Мы можем пользоваться ToString для отладки, но его назначение - сделать строку.
3. Возможно, нам в отладке не нужна вся строка, которую мы собираемся получить из ToString.
4. Тесты и покрытие. Мы должны покрыть метод ToString тестами, либо явно сделать игнор этого метода в покрытии.