9 крышесносных правил для тех, кто хочет писать чистый код

Старт:14.12.2024

Срок обучения:72 ч.

«Динамическая песочная сказкотерапия для дошкольников и учащихся начальной школы»

Дистанционное обучение по программе Динамическая песочная сказкотерапия для дошкольников и учащихся начальной школы (72 часа) в ЦАППКК. ✍ Мы подберем вам подходящий курс, пишите!

9 000 ₽

Подробнее

Правило 1: Используйте осмысленные имена переменных и функций. Например, вместо x используйте пользовательский_ID. Это существенно повышает читаемость кода и снижает время на его сопровождение.

Правило 2: Придерживайтесь согласованного стиля кодирования. Выбирайте и строго придерживайтесь одного стиля форматирования: правила отступов, кодировки, именования. Это позволит избежать несогласованностей и сделает код более легким для восприятия.

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

Правило 4: Комментируйте код только когда необходимо. Достаточно краткого объяснения, если есть нетривиальные логические решения или концепции, которые не ясны из названия функции или переменной. Избегайте лишних комментариев.

Правило 5: Используйте подходящие данные типы. Если вы работаете с целыми числами, используйте целочисленный тип данных, а не тип данных с плавающей точкой. Неправильный тип данных может привести к непредвиденным ошибкам.

Правило 6: Всегда проверяйте входные данные. Ваши программы не должны быть уязвимыми к ошибочным или некорректным входным данным. Проверка входных данных позволит предотвратить ошибки и скрыть неприятные сюрпризы.

Правило 7: Используйте правильно инкапсуляцию переменных и функций. Продумайте доступ к данным и скрывайте внутреннюю реализацию, чтобы уменьшить зависимость отдельных частей. Это важно для масштабируемости.

Правило 8: Контролируйте длину функций и файлов. Очень длинные функции или файлы усложняют отладку и сопровождение. Разумно делите код на более мелкие части (модули или классы)

Правило 9: Регулярно пересматривайте и улучшайте свой код. Не бойтесь переписать или перестроить код, который стал слишком сложным. Это поможет вам избежать проблем с масштабируемостью и читаемостью в последующем.

Наглядность и самодокументируемость: как сделать код понятным без комментариев

Используйте осмысленные имена переменных и функций. «counter» лучше, чем «i». «calculateTotalSales» понятнее, чем «func1». Наименования должны отражать назначение данных и блоков кода.

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

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

Используйте константы для магических чисел. Вместо `3.14159` используйте `PI = 3.14159`. Это делает код более читаемым и позволяет легко изменить значение в одном месте.

Следуйте стилю кодирования вашей команды/проекта. Согласованный стиль делает код более предсказуемым и упрощает совместную работу. Важно – один стиль для всего проекта.

Правильно используйте выразительные конструкции языка. Линии кода `if (age >= 18) { ... }` более понятны чем `if (x == 1) { ... }`, если `1` связан с достижением совершеннолетия. Используйте преимущества сокращений языка.

Используйте хорошо документированные библиотеки и фреймворки. Продуманный API уже содержит информацию об использовании.

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

Понимание принципов DRY и KISS: избавьтесь от дублирования и упрощайте код

DRY (Don't Repeat Yourself) - ключевой принцип. Если ты видишь похожий код в нескольких местах – перепиши его как функцию или метод. Это сократит код, упростит поддержку и снизит вероятность ошибок.

Пример:

• Плохой код:
• if (user.age > 18) { // ...код для взрослых пользователей... } if (customer.age > 18) { // ... тот же код для клиентов... }
• Хороший код (DRY):
• function checkAge(person) { if (person.age > 18) { // ... код обработки взрослого пользователя... } return; } checkAge(user); checkAge(customer);

KISS (Keep It Simple, Stupid) фокусируется на минимализме. Используй только то, что нужно. Сложность ведет к ошибкам и сложностям при отладке.

Пример:

• Плохой код:
• function calculateTotalCosts(orders, taxes, discounts, shipping, bonus) { // Очень длинная функция... }
• Хороший код (KISS):
• function calculateTotalCostOrder(order){ return order.price * order.qty ; } const totalAll = orders.reduce((total, order) => total + calculateTotalCostOrder(order);,0);

Рекомендации:

1. Разделяй большой блок кода на более мелкие, логически связанные функции.
2. Используй переменные: храни повторяющиеся значения в переменных.
3. Ищи возможности применения имеющихся функций и методов (вместо написания схожего).

Работа с errror handling: как правильно обрабатывать исключения, не раздувая код

Важно: Используйте try-except блоки только там, где это действительно необходимо. Не обёртывайте всю функцию. Ограничьте обработку исключений узкими проблемными зонами.

Пример 1 (плохо):

def process_data(file_path): try: with open(file_path, 'r') as file: data = file.read() # Все действия с данными тут result = process_calculations(data) return result except Exception as e: print(f"Ошибка: {e}") return None

Пример 2 (лучше):

def process_data(file_path): try: with open(file_path, 'r') as file: data = file.read() except FileNotFoundError as e: print(f"Файл не найден: {e}") return None try: result = process_calculations(data) return result except ValueError as e: print(f"Некорректные данные: {e}") return None

Рекомендации:

• Выделяйте конкретные типы исключений (FileNotFoundError, TypeError, ValueError). Не ловите все ошибки (Exception) без необходимости.
• Делайте подробные сообщения об ошибках, чтобы облегчить отладку. Включите логирование.
• Ловите исключения локально. Если функция не должна обрабатывать исключения, то не надо их обрабатывать.

Следование этим правилам поможет вам писать код, который не только обрабатывает ошибки, но и сохраняет ясность и читаемость.

Использование структур данных: применение подходящих данных для задач

Для эффективной работы выбирайте структуру данных, идеально подходящую для ваших задач. Список – для упорядоченных списков, хэш-таблица – для быстрого поиска.

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

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

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

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

Модульность и разделение задач: как написать код, который легко поддерживать

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

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

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

Пример: Если у вас есть два класса, которые обрабатывают файлы разного формата, но выполняют одни и те же действия, создайте базовый интерфейс с методами «читать» и «записывать». Реализуйте интерфейс в каждом конкретном классе. Таким образом, код, который использует эти классы, сможет работать с обоими форматами, не изменяясь при добавлении нового формата.

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

Пример: Вместо магических чисел `10` и `20`, используйте `MAX_VALUE = 10` и `MIN_VALUE = 20`. Это сделает код прозрачным и упростит внесение изменений, связанных с этими параметрами.

Тестирование кода: эффективное покрытие и оптимизация

Для достижения 100% покрытия кода тестами, используйте фреймворк и инструменты автоматического тестирования, адаптированные под свой язык программирования (например, pytest для Python, JUnit для Java).

Оптимизация тестов:

• Используйте модульность и DRY-принцип (Don't Repeat Yourself) в написании тестов.
• Создавайте тесты, которые проверяют граничные значения и исключительные ситуации (валидацию входных данных).
• Автоматизируйте выполнение тестов. Это поможет выявлять ошибки на ранних этапах разработки.

Примеры оптимизации:

• Протестируйте, что функция возвращает ожидаемый результат при корректных данных.
• Протестируйте работу функции с некорректным вводом, в т.ч. с пустыми значениями, предельными значениями и вне диапазона.

Следите за размером и временем выполнения тестов:

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

Вопрос-ответ:

Какие конкретные приёмы помогут мне избежать "спагетти-кода" на практике, особенно при работе над большими проектами?

Чтобы избежать "спагетти-кода", важно с самого начала проекта чётко структурировать код и придерживаться соглашений об именовании переменных и функций. Разбивайте сложные задачи на более мелкие, управляемые функции с понятной логикой. Использование модулей и классов позволит организовать код по функциональным блокам. Важное правило – не бояться разбить длинные функции, если это делает код более понятным и читаемым. Чем больше функций, тем детальнее должна быть документация, описывающая назначение каждой функции и принимаемые ею аргументы. Кроме того, пользуйтесь системами контроля версий (как Git), чтобы отслеживать изменения и разрабатывать код поэтапно. Это позволяет легко "откатить" некорректные изменения. При разработке больших проектов необходимо не только делить код на компоненты, но и документировать их функциональность максимально подробно с примерами использования. Это позволит всем членам команды легко понимать назначение каждой функции и как ее использовать. Наконец, регулярно проводите ревью кода и старайтесь искать возможности упрощения и обобщения кодовой логики.

Как понять, что мой код уже достаточно чистый? Есть ли какие-то объективные критерии оценки читабельности кода?

Чистота кода – это субъективное представление, однако существуют критерии, позволяющие оценить степень его понятности и поддерживаемости. Важно, чтобы ваш код был легко читаем, без сложного и запутанного синтаксиса. Изучайте код с «точки зрения» человека, который его будет использовать или поддерживать в будущем. Функции и переменные должны быть чётко названы, отражая их предназначение. Если вы перечитываете свой код и вам сложно понять, что делает та или иная функция, значит, код нуждается в улучшении. Необходимо продумать структуру кода, использование отступов и комментариев (но не злоупотребляйте ими). В идеале, код должен быть настолько понятен, чтобы не требовать длительного изучения, чтобы каждый участник мог быстро и эффективно понимать его смысл. Ключевым критерием является возможность быстрого понимания логики кода другими разработчиками, без необходимости длительного изучения.

Может ли стандартизация кода привести к потере гибкости и индивидуальности стиля, особенно при работе в команде?

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

Как избежать лишнего копирования и вставки кода, когда это может привести к ошибкам и затруднить поддержку?

Избегайте копирования и вставки кода, как можно скорее переписывайте его в виде функции или методов. Это снижает вероятность ошибок при корректировке, упрощает внесение изменений, и помогает быстрее находить и исправлять ошибки, ведь вы взаимодействуете только с одним блоком кода. Используйте функции для повторного использования кода. Это помогает предотвратить ошибки, связанные с неодинаковым оформлением и поведением повторяющихся участков кода. Если код отличается только параметрами, подумайте о создании функции с параметрами (аргументами). Изучите возможности использования абстрактных классов, интерфейсов или обобщённых типов данных, чтобы создать повторно используемый код. Имейте в виду, что общими правилами для всех случаев нет, поэтому необходимо принимать решения в каждой конкретной ситуации, исходя из ситуации, придерживаясь правил и понимания кодовой базы.