5 полезных и 5 вредных советов для поддерживаемого кода
По обыкновению, код пишется для людей. Давайте рассмотрим подборку полезных и не очень советов для создания поддерживаемого кода.
Изучение чего-либо и достижение вершины невозможно без знаний и практики. Знания дадут вам паттерны, принципы и best practices, которые пригодятся, чтобы стать лучшим в своей области. Но эти знания должны быть закреплены на ваших пальцах и в глазах постоянной практикой и тяжелой работой.
Научиться создавать поддерживаемый код – дело не из легких. Никому еще не удавалось без практики, спотыканий и неудач достигнуть цели. Не существует другого способа или хитрости, чтобы это обойти.
5 полезных советов для написания поддерживаемого кода
Рассмотрим несколько советов, с которыми будет проще овладеть искусством "чистого кода".
Что скрывает в себе имя
Хорошее имя несет смысл – не жалейте сил на подбор и переименуйте существующие объекты. Все, кто будет читать ваш код, оценят это.
Чтобы облегчить процесс "придумывания" имени для переменной, функции или класса, запомните, что оно должно отвечать на три вопроса:
- Для чего существует переменная?
- Что она делает?
- Что использует?
Нужно серьезно отнестись к названиям, так как впоследствии это может стать наиболее значимой проблемой в процессе написания поддерживаемого кода.
Функции должны выполнять только одно действие
Функции, как правило, – основной элемент организации кода в любом ЯП, и умение их создавать хорошо структурированными – суть чистого кода.
Созданная функция должна быть компактной и не содержать большое дерево вложенности – не больше одного или двух уровней. Такой подход улучшает читабельность и внешний вид кода. Обязательным правилом поддерживаемого кода является проверка на нахождение всех элементов функции в одном уровне абстракции.
Допускать перемешивание этих уровней нежелательно (даже критично), т. к.:
- это запутывает;
- вы можете забыть, что происходит в коде;
- со временем приводит к неуправляемому коду.
Аккуратнее с комментариями
Умеренное количество комментариев – идеальный вариант. Существует очень много примеров кода, где уровень полезности комментирования равен нулю. Не следует объяснять каждую строку кода (особенно с очевидным смыслом), не загромождайте код программы бесполезным текстом. Если оставляете документацию, то потрудитесь создать четкое, внятное, лаконичное и правдивое описание.
Помечайте свои комменты датой, чтобы другой разработчик смог понять актуальность написанного – это делает проще поддержку и помогает навести порядок в структуре кода.
Помните, что лучше написать несколько комментариев, чем хранить между строками "роман Толстого" – не создавайте беспорядок, а посвятите время уборке.
Сначала был "try-catch"
Обработка ошибок – это необходимая составляющая работы программиста. Однако проблема заключается не в самом процессе, а в аккуратном подходе и красивом способе отлова.
Есть программы, в которых обработчиков ошибок больше, чем логики, вследствие чего все становится запутанным, разрозненным и теряется смысл всего кода. Создавайте изящные блоки обработки, чтобы они не влияли на надежность программы.
Помните, что каждое созданное вами исключение должно работать только в том направлении, для которого оно создавалось, а также выполнять поставленную задачу. Устраняйте неиспользуемые блоки try-catch.
Форматирование в приоритете
Отформатированный код может охарактеризовать его автора. Если текст программы идет сплошным полотном и не имеет четкого начала и конца, это сильно ударит по вашей репутации разработчика. Старайтесь максимально упорядочивать элементы кода, уделять внимание отступам и использовать одну нотацию для всего проекта.
Если думаете, что это важно только для профессионального разработчика, вы ошибаетесь. Созданный функционал может измениться в следующем релизе, а читаемость кода не изменится никогда.
5 вредных советов для написания поддерживаемого кода
Теперь перейдем к антисоветам.
Меньше – лучше
Пишите код как можно более сокращенным и понятным только вам, т. к. "подсиживания" никому не нужны. Используйте больше неочевидных оборотов и возможностей языка:
// код из jQuery i = i ? i < 0 ? Math.max(0, len + i) : i : 0;
Стандарты для слабаков
В привычных местах, где используются i и j, применяйте другие буквы – так вы бросите вызов мейнстриму.
Называйте переменные (и не только) русскими словами в английской раскладке: var peremennaya – то, что требуется.
Чтобы совсем уничтожить читающего, нужно в коде как можно чаще вставлять похожие переменные: data и date. Если "новенький" хочет занять ваше место, пусть тренирует внимательность.
Сокрытие информации
Чтобы веселиться по полной, используйте разные переменные для одного и того же: customers, clients, people – с виду разные переменные, но весь сок в том, что через некоторое время вы сами забудете, что тут к чему, и будете сильно удивлены.
Еще более удачный вариант внесения "ясности" – применение символов "_" и "__" везде, где душе угодно. Желательно вставлять эти знаки в произвольном порядке и без особого смысла.
Внутри и снаружи
Не забывайте чаще применять одинаковые переменные:
function ninjaFunction(elem) {
// 20 строк кода, работающего с elem
elem = elem.cloneNode(true);
// еще 20 строк кода, работающего с elem
}
Очень элегантный способ сбить с толку программиста, возомнившего себя гуру.
Работа с функциями
Если вы думаете, что функция обязана выполнять только одну задачу, то вы ошибаетесь! Функция должна быть универсальной, перегруженной разношерстными "обязанностями".
Включайте правило "Даешь странное имя!", когда придумываете название функции: это обязательно собьет с толку потенциального конкурента.