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

Несколько практических советов от настоящих индейцев.

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

2. В простом и понятном коде сложно сделать ошибку, а сделав легко найти. Следовательно, написанный код должен быть понятен с первого взгляда. Настоящие индейцы производят немногословный и хорошо отформатированный код. После написания и отладки готовый код ещё раз просмотриваем на предмет как его можно сделать более лаконичным и понятным. Настоящие индейцы пытаются сделать код более понятным прежде всего не для себя, а для других, даже если другими этот код никогда просматриваться не будет.

3. Copy/Paste vs. повторное использование. Copy/Paste — это разносчик багов, что есть плохо. Но шизиловка, когда каждые две строчки кода оформляются в виде отдельного метода ни чем не лучше. Поэтому настоящие индейцы копипейстят, но только один раз. Если некоторый фрагмент кода повторяется уже в третий раз, то это хорошая причина для оформления его в виде отдельного метода.

4. Настоящие индейцы не боятся длинных линейных методов, они не любят запутанных ветвистых уродцев, в которых легко прятаться багам. Существуют задачи, например, по генерации кода, которые выполняются в несколько последовательных шагов. Разбиение таких задач на несколько методов, которые используются только один раз не имеет никакого смысла, особенно учитывая, что часто приходится передавать контекст в эти методы, что выливается в длиннючий список параметров. Лучше отделить более менее независимые блоки коментариями, кратко описывающими суть действия. Если же выполняемая операция становится действительно сложной и плохоуправляемой, а рефакторинг такого метода приводит к выделению методов с невменяемым числом передаваемых параметров, то настоящие индейцы выносят такой код в отдельный класс. В отличии от метода в отдельном классе вместо передаваемых параметров можно использовать контекст самого класса.

5. Настоящий индеец думает 10 раз прежде чем объявить статическую переменную. Статический контекст самый злобный источник багов и кривого дизайна. Даже если не будет багов, то кривизну дизайна в дальнейшем придётся выкривлять с помощью линз с обратной кривизной. Если же индеец всё же решилися на использование статического контекста, то он возвращается к началу данного пункта ещё раз. В принципе, статические переменные можно использовать для кеширования некоторых данных при соблюдении правил гигиены в многопоточных приложениях. В остальных случаях как правило стоит серьёзно задуматься.

6. Автоматическое тестирование. Настоящие индейцы обязательно пишут тесты для тестирования библиотечного кода, который используется другими частями приложения. Прикладной код тоже иногда может автоматически тестироваться, но это может оказаться банально дорого, т.к. тестирование библиотечного кода и например UI — это принципиально разные вещи. Юнит тест для библиотеки не стоит практически ничего, подготовка и периодическое изменение теста для UI может занять больше времени, чем работа над самим UI.

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

8. Настоящий индеец знает, что только что написанный код обязательно будет меняться либо им самим, либо кем-то другим, может быть через 5 минут, может быть через 5 лет. В трудно модифицируемом коде сложно исправлять существующие баги и не вностить новые. Поэтому, основной критерий качества кода для настоящего индейца — это готовность кода к модификациям и способность после этого оставаться готовым к следующим модификациям.