Распространенные ошибки · Руководство по стилю C# для чистого и масштабируемого кода

Типичные ошибки

Чистый код не возникает случайно. Это результат осознанной работы людей, которые стараются мыслить и писать код как единая команда. Разумеется, не все идет по плану. Как бы вы ни старались, нечистый код неизбежно появляется, поэтому его нужно уметь находить. «Запах кода» — характерный признак того, что в проекте может скрываться проблемный участок. Перечисленные ниже симптомы не всегда означают серьезную проблему, но при их появлении код стоит проверить:

— Загадочные имена. Хорошая загадка уместна где угодно, но не в правилах написания кода. Классам, методам и переменным нужны понятные, однозначные имена. Подробнее см. раздел об именовании. — Избыточная сложность. Чрезмерное проектирование возникает, когда класс пытаются заранее подготовить ко всем возможным потребностям. Так появляется «божественный объект» (God object) с длинными методами или огромный класс, который делает слишком много. Разделите монолитный класс на небольшие специализированные части, каждая из которых отвечает за одну задачу. — Негибкость. Небольшое изменение не должно требовать множества исправлений в других местах. Если это происходит, проверьте, не нарушен ли принцип единственной ответственности.

Объект с несколькими обязанностями ломается чаще, потому что предусмотреть все взаимодействия сложнее. Если метод выполняет одну задачу и после изменения по-прежнему работает правильно, остальная система также должна продолжить работу.

— Хрупкость. Если после небольшого изменения перестает работать вся система, это часто указывает на проблему в структуре кода. — Неподвижность. Код нередко можно повторно использовать в другом контексте. Если перенести его мешает большое число зависимостей, отделите основную логику от окружения.

— Дублирование кода. Если видно, что код скопирован и вставлен, пора выполнить рефакторинг. Вынесите общую логику в отдельный метод и вызывайте его из остальных методов. Копии сложно сопровождать: при каждом изменении приходится исправлять несколько мест. Подробнее см. раздел о принципе DRY.

— Избыточные комментарии. Они помогают объяснить неочевидный код, но ими легко злоупотребить. Пошаговые пояснения к каждой переменной или инструкции не нужны. Лучше дать методу или классу имя, ясно выражающее намерение. Чем меньше и понятнее фрагменты логики, тем меньше пояснений им требуется.