Эта статья – краткий обзор первой половины книги Чистый код.

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

Для самых нетерпеливых

Основные тезисы для тех, кто не хочет читать эту прекрасную статью целиком.

• Думайте над именами

• Не делайте код слишком чистым

• Следуйте стандартам языка или вашей команды

• Программист не должен заниматься форматированием

Чистый vs грязный код

Чистый код легко читается, изменятся и поддерживается. Это тот код, с которым легко работать и вносить новый функционал.

Грязный код затормаживает разработку новых фич из-за того, что программистам тяжело с ним работать.

Принципы

Призваны помочь борьбе с грязным кодом, делая жизнь программистов легче.

Названия

Исчерпывающие названия

Для того чтобы выбрать название, задайте себе вопрос: “что делает эта функция?” или “что обозначает эта переменная?”. Если вы не можете ответить на вопрос – займитесь рефакторингом.

Самое сложная вещь в программировании – это нейминг.

Поэтому стоит подумать хотя бы минуту, прежде чем давать имя чему-либо.

Если вы понимаете, что делает функция, которую вы написали месяц назад – поздравляю, у вас получилось подобрать хорошее название.

Дополнение контекстом

Как правило, в современных языках программирования существуют модули, которые разделяют кодовую базу на части. Следовательно, каждое название находится только в своей зоне видимости и не требует дополнительного уточнения его принадлежности.

Кодировка признаков

Кодирование признаков в именах бесполезно – IDE и так даёт всю нужную информацию о переменной. Также, оно ухудшает удобочитаемость кода и затрудняет автодополнение при вводе.

Одна концепция – одно имя

Каждая концепция должна обозначаться одним и тем же словом – иначе придётся разбираться чем одно отличается от другого.

Функции

Функции – как хорошие шутки: короткие и по делу.

– DeepSeek

Функции выступают основными строительными блоками программы. Поэтому, важно писать их так, чтобы было понятно, что происходит в коде.

Одно действие

Функция должна выполнять только одну операцию. Она должна выполнять её хорошо, и ничего другого она делать не должна.

– Роберт Мартин

Если название функции намекает на то, что она выполняет несколько действий, разбейте её тело на две новые функции. Таким образом, теперь она выполняет только одну задачу – объединение двух новых функций.

Компактность

Первое правило: функции должны быть компактными. Второе правило: функции должны быть еще компактнее.

– Роберт Мартин

Чем компактнее функция, тем лучше. Но как и с любой вещью важно не переусердствовать – если функция легко читается, то зачем её разделять?

Аргументы

Чем меньше аргументов, тем лучше. Три или четыре – уже много. Для уменьшения их количества можно объединять в структуры, разделяя по группам.

Форматирование

Программист не должен заниматься форматированием.

В каждом языке программирования есть программы для форматирования кода. Их преимущество в том, что они работают быстро и соблюдают все стандарты языка.

Также, их можно настраивать, чтобы соблюдать особые правила выработанные в команде.

Стандарты

Важный аспект чистого кода это соблюдение стандартов. Они есть почти во всех языках программирования.

• Python – PEP 8

• Rust – The Rust Style Guide

• C++ – Google C++ Style Guide

Просто следуйте им. Это снизит когнитивную нагрузку на мозг в спорных ситуациях, так как можно сделать так, как прописано в стандарте.

Две шапки

Одна для написания кода, а другая для рефакторинга.

Первая

Фокусируйтесь только на написании функционала. Не заморачивайтесь о длине функций, названиях переменных и т.д. Главная задача этой шапки – получить работающий код.

Вторая

Приводите написанный код в читаемое состояние. Если вдруг стало нужно написать какой-то функционал – меняйте шапку.

Комментарии

Хороший комментарий должен описывать подробности, которые не могут быть выражены кодом. Например, примеры каких-то значений.

Не комментируйте то, что и так очевидно. Это не принесёт пользу, а наоборот навредит читаемости.

Удаляйте комментарии, которые перестали быть актуальными после изменений кода, так как они описывают уже не тот функционал, который был раньше.

Чрезмерный перфекционизм – плохо

Занимаясь бесконечным рефакторингом, вы перестаёте писать функционал. Доводите код до состояния достаточно чисто, а не до идеала – иначе вы никогда ничего не напишете.

Пожалуй это главное, чего стоит придерживаться, когда пытаешься писать чистый код.

Конец

Надеюсь, статья была полезной. Другие мои статьи можно найти в моём блоге или прямо тут на Хабре.