Здравствуйте, _Mihail, Вы писали:

IT>>1. Настоящий индеец прежде всего заходит в меню Debug и в диалоге Exceptions включает галку Thrown на CLR Exceptions для managed языков. Это позволяет сэкономить не просто хучу, а туеву хучу времени при поиске ошибок. Отсюда следствие — настоящие индейцы не используют логику на исключениях, иначе весь кайф пропадает.

_M>Не знаю что там за ошибки такие ловятся,

Это самый быстрый способ локализовать проблему. Быстрее просто не бывает.

_M>но по крайней мере зверя ContextSwitchDeadLock я буду включать только через свой труп — он мне столько нервов попортил...

Не включай. Я лично вообще такого исключения ни разу в жизни не видел.

IT>>4. Разбиение таких задач на несколько методов, которые используются только один раз не имеет никакого смысла

_M>Согласен, только иногда существуют такие блоки в этих линейных методах, которым очень легко придумать название отдельного метода и оно очень четко функциональность этого блока описывает... В общем в таком случае получается, что дробление метода только увеличивает понятность, т.к. с хранением этих мелких методов почему-то проблем не возникает — их легко находить, а на практике и вообще не надо их находить, т.к. достаточно посмотреть на название метода, чтобы понять, что там делается. И совершенно не важно, кто этот метод вызывает, а кто вызывается им.

Да ради бога. Я лишь имею в виду, что разделение на методы ради разделения на методы там где это не нужно, это так же плохо как и неразделение на методы, там где это нужно.

_M>Золотые слова! Только что-то сомневаюсь, что покрытие библиотечного кода юнит тестами будет отлавливать много багов. У меня лично в таком коде очень редко ошибки появляются, а те что появляются — и без ЮТ о себе заявляют очень быстро, т.к. общие методы используются часто. Но, конечно, и создавать тесты для такого кода очень просто.

Редкость и быстрота отлова — это плохие отговорки. Достаточно однажды, например, написать новый функционал, который слегка где-нибудь сломает старый, закомитить результат и уехать в отпуск на месяц. Если такой баг заблокирует работу нескольких человек, то либо они достанут тебя с берега лазурного моря и испортят весь кайф, либо порвут тебе жопу на немецкий крест когда ты вернёшься. Другими словами, дело не в простоте отлова и редкости. Дело в уровне ответственности. Чем чаще используется один и тот же код, тем больше должно быть контроля, что его изменение не приведёт к фатальным или блокирующим последствиям.