3 совета по написанию чистого кода с примерами Python
Что такое «чистый код»? Хотя существует множество определений, наиболее популярным из них является то, что большинство людей согласны с тем, что «чистый код - это код, который легко понять и который легко изменить или поддерживать».
Поскольку код чаще читают, чем пишут, постоянное напоминание себе о том, что нужно практиковаться в написании чистого кода, имеет решающее значение в нашей карьере.
В этой статье я поделюсь с вами некоторыми уроками, которые я накопил за эти годы, а также приведу несколько примеров на Python. С учетом сказанного, эти принципы обычно применимы к большинству языков программирования.
TL;DR
- Будьте последовательны, называя вещи
- Избавьтесь от путаницы при именовании вещей
- Избегайте двойных негативов
- Напишите понятный код
- Не злоупотребляйте комментариями
1. Называйте вещи правильно
Избавьтесь от путаницы
Несмотря на то, что это самый старый трюк в книге, это простейшее правило, которое мы часто забываем. Всегда всегда спрашивайте себя перед тем, как назвать папку, функцию или переменную: «Если я назову ее так, может ли это означать что-то еще или сбить с толку других людей?»
Общая идея здесь состоит в том, чтобы всегда исключать любую путаницу при именовании чего-либо.
Причина, по которой expired - менее идеальное имя, состоит в том, что expired само по себе неоднозначно. Новый разработчик, работающий над проектом, не узнает, является ли expired датой или логическим значением.
Будьте последовательны в именовании
При работе в команде чрезвычайно важно поддерживать последовательность на протяжении всего проекта, чтобы избежать путаницы и сомнений. Это относится к именам переменных, именам файлов, именам функций и даже структурам каталогов.
Ничего нельзя называть исключительно на основе ваших индивидуальных предпочтений. Всегда проверяйте, что уже написали другие люди, и обсуждайте это, прежде чем что-либо менять.
Дополнительные советы при выборе имен
- Переменные - это существительные (т.е.
product_name). - Функции, которые что-то делают, - это глаголы (например,
def compute_user_score()). - Логические переменные или функции, возвращающие логическое значение, являются вопросами (например,
def is_valid()). - Имена должны быть описательными, но не слишком подробными (например,
def compute_fibonacci(), а неdef compute_fibonacci_with_dynamic_programming()).
2. Избегайте двойных отрицательных слов.
«Можете ли вы убедиться, что вы не забудете позже выключить свет?»
Фу. Итак, выключить свет или нет? Погодите, позвольте мне прочитать это еще раз.
Согласитесь, двойное отрицание просто сбивает с толку.
Если вам придется прочитать его больше одного раза, чтобы убедиться, он пахнет.
3. Напишите понятный код.
В прошлом я помню, как мне неопределенно говорили, что инженеры должны разбрасывать комментарии повсюду, чтобы «улучшить качество кода».
Эти времена давно прошли. Вместо этого инженерам нужно писать понятный код, понятный людям. Например, мы должны попытаться зафиксировать сложную логику в описательной и самочитающейся переменной.
Не злоупотребляйте комментариями
Как и сам код, комментарии тоже могут устареть.
Люди часто забывают обновить комментарии по мере рефакторинга кода. Когда это произойдет, сами комментарии косвенно станут причиной неразберихи.
Всякий раз, когда вы чувствуете необходимость написать комментарий, вы всегда должны переоценивать код, который вы только что написали, чтобы увидеть, как его можно сделать более понятным.
В этом разделе мне очень понравилось читать статью ниже, которая намного лучше объясняет, почему мы не должны злоупотреблять комментариями при написании кода:
Примеры того, когда писать комментарии
Один из сценариев, в которых я бы рассмотрел возможность использования комментариев, - это когда мне нужно использовать нарезку. Обычно это вызывает вопросы вроде «Почему мы так поступаем? Почему не другие индексы? » и так далее.
Другой пример:
Представьте, что вы новый разработчик, впервые просматривающий приведенный выше код.
Первое, что приходит мне в голову: «Почему мы случайным образом ждем две секунды на каждый запрос, который делаем?»
Оказывается, исходный разработчик, написавший код, просто хотел, чтобы мы ограничили количество запросов, отправляемых к стороннему API.
Всегда ставьте себя на место других (например, «Как другие интерпретируют мой код?»). Если вы нарезаете или используете определенный индекс из списка (например, array[3]), никто точно не узнает, зачем вы это делаете.
Как мне применить эти знания?
Никто не может писать чистый код с первого дня. Фактически, все начинают с написания «плохого» или «некрасивого» кода.
Как и в большинстве случаев в жизни, чтобы быть в чем-то хорошим, вам просто нужно практиковаться снова и снова. Вы должны потратить часы.
Помимо практики, мне нравятся следующие вещи:
- Продолжайте задавать себе такие вопросы, как «Есть ли лучший способ написать это? Это сбивает с толку других? "
- Участвуйте в проверках кода.
- Изучите другие хорошо написанные кодовые базы. Если вам нужны примеры хорошо написанного, чистого и питонического кода, посмотрите библиотеку запросов Python.
- Поговорите с людьми, обсудите или обменивайтесь мнениями, и вы научитесь намного быстрее.
Последние мысли
Написание чистого кода трудно объяснить многим нетехническим людям, потому что для них это практически не приносит немедленной пользы для бизнеса компании.
Написание чистого кода также требует много дополнительного времени и внимания, и эти два фактора косвенно влияют на затраты для бизнеса.
Однако со временем эффект наличия чистого кода в базе кода имеет решающее значение для инженеров. Благодаря более чистой кодовой базе инженеры смогут быстрее доставлять код и развертывать приложения для достижения бизнес-целей.
Вдобавок ко всему, наличие чистого кода имеет решающее значение, чтобы новые соавторы или участники могли быстрее приступить к работе, когда они начнут новый проект.
