В качестве реакции на мой предыдущий пост о защитном программировании, один из моих читателей прислал мне такой вопрос:

[Один] очень известный сценарий защитного программирования встречается, когда входным параметром является

IEnumerable




public class Publisher
{
    public Publisher(IEnumerable<Subscriber> subscribers)
    {
        // defensive copy -> good or bad?
        this.subscribers = subscribers.ToArray();
    }
    //  …
}

Один из моих читателей, Барри Гайлз, недавно написал мне и задал достаточно интересный вопрос, который, по моему мнению, достоен обсуждения:

«Недавно я столкнулся с одной интересной ситуацией на работе: я производил ревью кода и вставил защитные проверки – одну для проверки аргумента конструктора на null, одну для проверки на null значения, возвращаемого из свойства. У меня также имелись утверждения для закрытых методов, которые я использовал для того, чтобы явно указать мои предположения.
«Похоже, что преобладающей практикой среди моих коллег по команде является опускание проверок и допущение падений. Если быть честным, я борюсь с этой концепцией, так как я уже привык разрабатывать посредством защитного программирования и считал это хорошей практикой. Я практически уверен, что дело обстоит так же в большей части руководств и записей в блогах.
«Вы не могли бы дать совет относительно того, почему лучше программировать в защитном стиле, вместо того, чтобы позволить коду провалиться и затем проверять трассировку стека?»

Даже если код тривиален, вы всё равно должны его тестировать.
Пару дней назад, Роберт Мартин опубликовал пост «Прагматичность TDD», (здесь лежит перевод — прим.переводчика) где он рассказал о том, что не тестируют абсолютно весь код. Среди исключительных ситуаций, когда не стоит применять TDD, дядя Боб упоминает написание GUI-кода, и я вижу смысл в таких утверждениях, но среди исключений есть парочка, на мой взгляд, нелогичных.

Итак, моя последняя запись: стартап-ловушка (здесь её перевод — прим. переводчика) наделала много шуму. Среди людей, выражающих согласие и поддержку, нашлась и группа людей, которая была категорически не согласна. Я не буду здесь резюмировать все разногласия, ибо в этом месяце я уже исчерпал свой лимит ругательных слов. Но одним альтернативным мнением я проникся и считаю нужным его обсудить.
Речь о старом конфликте «прагматизм против догматизма».

Внимание! Статья представляет собой перевод поста из блога Марка Симэна.

Mark Seeman — архитектор программного обеспечения, проживающий в Копенгагене. Ранее работал разработчиком и архитектором в компании Microsoft. Сейчас Mark является независимым коснультантом. Также Mark является автором небезызвестной книги Dependency Injection in .NET
Статья представляет собой перевод поста из блога Mark Seeman.
В комментариях, исключая, разумеется, обсуждений самого поста Марка, хотелось бы услышать мнения насчёт качества перевода и главное стоит ли в будущем при появлении интересных записей делать перевод и выкладывать сюда (а может и из его старых записей что-то перевести)?
Далее идёт перевод поста Марка.

Эта статья затрагивает тему использования разработчиками инструментов повышения производительности.
Время от времени я бываю втянутым в жаркие дебаты на счёт преимуществ и недостатков ReSharper. Эти дебаты происходят обычно в Твиттере, где ограничением являются 140 символов на сообщение, что является не очень благоприятным условием для ведения детальных дискуссий. Я не хочу пустопорожней болтовни, так что начнём детальное обсуждение.

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