Лучшие практики Python для специалистов по обработке данных

Немало уже сказано о том, что специалисты по анализу и обработке данных не пишут чистый код. И тому есть объяснение: большая часть всей предварительной работы (разведочный анализ данных, отбор признаков и первичная обработка) выполняется в Jupyter Notebook, где мы не заботимся о качестве кода.

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

Код, который пишут специалисты по анализу и обработке данных для запуска модели в массовое использование, по большей части не соответствует рекомендациям по написанию кода. Например, руководству по стилю PEP8. PEP расшифровывается как Python Enhancement Proposal (Предложения по развитию Python). PEP  —  документ, в котором описываются новые возможности Python и такие его аспекты, как дизайн и стиль. Каждая новая возможность предлагается, а затем рассматривается членами сообщества, которые вносят свой вклад в развитие Python (это разработчики Google, Microsoft и других гигантов сферы информационных технологий). Но зачем следовать каким-то руководствам?

Однажды Гвидо ван Россум, основатель Python, заметил: «Код читают намного чаще, чем пишут». Можно потратить несколько минут или даже целый день на написание фрагмента кода, отвечающего за аутентификацию пользователя. Написав его раз, уже не будешь писать его снова, но непременно будешь перечитывать. Этот кусок кода может оставаться частью проекта, над которым ведётся работа. Всякий раз, возвращаясь к этому файлу, будешь вспоминать, что делает этот код и для чего ты его создавал. Так что лёгкость чтения кода очень важна.

Теперь обратимся к рекомендациям, изложенным в PEP8.

Стиль именования

Переменные, функции, методы, пакеты, модули:

• Строчные буквы, слова разделены нижним подчёркиванием: например, check_pass 

2. Классы и исключения:

• Заглавная буква в начале, верхний регистр между словами вместо пробела: CamelCase, например, JustCounter.

3. Защищённые методы и внутренние функции:

• Знак подчёркивания впереди: _start_engine

4. Приватные методы:

• Два знака подчёркивания впереди: __foo(self, ...).

5. Константы:

• Верхний регистр: IP_SERVER='111.11.11.11'

6. Лучше использовать обратную нотацию:

elements = ... active_elements = ... defunct_elements ... Отступ

Используем 4 пробела и никакой табуляции.

Импортирование

Порядок импорта должен быть следующим:

1. Встроенные пакеты Python. 2. Пакеты сторонних разработчиков. 3. Локальные пакеты. Длина строки

Стараемся разбивать строку длиннее 80 символов.

even_numbers = [var for var in range(100) if var % 2 == 0]

Иногда дальше разбивать не получается, особенно в случае с цепочкой методов.

Пробел

Обязательно ставим пробел между двоеточием и значением ключа в словаре:

names = {'gagan': 123}

2. Ставим пробел между операторами в случае арифметических операций и операций присваивания:

var = 25 math_operation_result = 25 * 5

3. Не ставим пробел между операторами при передаче в качестве параметра:

def count_even(num=20): pass

4. Ставим пробел после запятой:

var1, var2 = get_values(num1, num2) Документация

Следуем рекомендациям в PEP 257, чтобы научиться документировать программу на Python.

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

"""Return the pathname of ``foo``."""

2. Многострочная документация должна состоять из:

Строки с кратким описаниемСлучая использования, если естьАргументовТипа возвращаемого значения и семантики, если не возвращено None

Пример:

class Car: """A simple representation of a car. :param brand: A string, car's brand. :param model: A string, car's model. """ def __init__(self, brand, model): self.brand = brand self.model = model class Car: """A simple representation of a car.

Заключение

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

---

Перевод статьи Gagandeep Singh: Best Python practices for Data Scientists