Когда мы пишем код, мы не должны забывать про тех, кто этот код читает. Это аксиома, поэтому мы стараемся писать такой код, чтобы тот парень, который его читает, не пришёл к нам в полночь с вилами.
При этом, можно пойти немного дальше, и подумать о тех, кто наш код будет отлаживать. Например, взаимодействовать с нашим классом. Например, это будет наш класс 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 тестами, либо явно сделать игнор этого метода в покрытии.