3 секретных оружия в арсенале Python
Я уже пишу на Python более 5 лет. Примечательно, что при этом мой арсенал инструментов с течением времени не увеличивался, а наоборот уменьшался. Многие из них оказывались необязательными или попросту ненужными, а из некоторых я просто вырастал.
В этой статье я осветил три главных инструмента, к которым привязался основательно. В отличие от остальных, ими я пользуюсь всё активнее.
Секретное оружие #1:
Kite: пишите код быстрее и реже обращайтесь к GoogleБольшинство редакторов кода предлагают функцию автоподстановки, которая выглядит примерно так:
Она использует документацию (иногда библиотеку) языка, чтобы предложить вам, например, имена функций или параметров.
Конечно же, это хорошо! Но что, если бы ваш редактор мог просматривать многолетние данные на GitHub и предлагать автоподстановку не только для имён функций, но и для целых строк кода?
Это лишь первая из трёх причин начать использовать Kite.
Причина 1: Подстановка строк кода
Kite просматривает вашу базу кода и переменные, часто используемые в интернете имена параметров, документацию и затем формирует отличные контекстные рекомендации вроде следующей:
Из документации KiteВышеприведённый пример показывает, как Kite может предсказывать используемые переменные даже там, где они названы обобщённо (вроде b) или в виде распространенных имён (вроде x или y).
…мы затратили около нескольких лет на семантическое индексирование всего кода с GitHub, создавая статистический вывод типов и богатые статистические модели, углублённо использующие семантическую информацию. — Адам Смит, Основатель и гендиректор Kite.
Вот видео пример работы автоподстановки. При желании вы также можете поиграться с ней в песочнице.
Причина 2: Copilot для документации
Если вас ещё ни разу не посылали… читать документацию, то вы, вероятно, не совершали таких ошибок, как я.
Несмотря на это, вам всегда стоит знакомиться с ней прежде, чем донимать старшего разработчика или даже искать ответы на StackOverflow.
Kite Copilot до смешного упрощает работу с документацией. Он выполняется параллельно с редактором и в режиме реального времени показывает пояснения для любого объекта/функции/и т.д., выделяемых курсором.
Уважаемый старший разработчик с моей первой работы, примите мои извинения. Теперь у меня точно не осталось оправданий, чтобы не обращаться за ответами сперва к документации. ????
Причина 3: выполняется локально и приватно
В добавок к вышесказанному этот инструмент разработан для выполнения локально, так что вы получаете невероятно быструю автоподстановку, возможность работать оффлайн и ваш код никогда не отправляется в облако.
Это особенно актуально для тех, у кого слабый интернет и тех, кто работает с базами закрытого исходного кода.
ИтогЯ пользовался Kite годами, и всё это время он становился только лучше. Имея более чем $17 миллионов вложений, эта компания уже никуда не денется, и сам инструмент по какой-то непонятной причине продолжает оставаться полностью бесплатным.
Всё, что требуется — это загрузить либо плагин Kite для редактора, либо copilot, который сможет установить этот плагин за вас. Доступно здесь.
Секретное оружие #2:
Mypy: стабилизация кода
Python использует динамическую типизацию. Вкратце, это означает, что любая переменная в любой момент времени может представлять любой тип данных (строка, целое число и т.д.) .
# Эти две переменные объявлены одинаково
# Python определяет тип данных сам, динамически
# строка
var_name = "string here"
# целое
var_name = 1234
Противоположным образом выглядит ситуация в статически типизированных языках, где переменные должны иметь один конкретный тип данных и всегда соответствовать ему.
# Многим ЯП нужно вручную указать тип данных
# строка
str var_name = "string here"
# целое
int var_name = 1234
Плюсы и минусы динамической типизации
Преимущество динамической типизации в том, что она благоволит ленивым. Писать код приходится меньше, благодаря чему может уменьшиться его захламление.
Тем не менее недостатков при этом куда больше и они весьма существенны:
- Как правило, вы сталкиваетесь с ошибками на более поздних стадиях разработки.
- Код выполняется хуже, поскольку Python вынужден постоянно определять типы.
- Функции менее стабильны, т.к. тип их данных ввода и вывода может быть изменён без предупреждения.
- Обслуживание кода существенно сложнее, т.к. другие могут не знать, какие типы ваши переменные имеют или могут получить.
Статическая типизация в Python
Запустите Mypy — бесплатный модуль Python, который позволяет использовать в нём статическую типизацию.
После выполнения pip install mypy можете рассмотреть один пример его использования:
# Объявление функции через нормальную динамическую типизацию mypy
def iter_primes():
# код
# Объявление этой же функции через статическую типизацию mypy
from typing import Iterator
def iter_primes() -> Iterator[int]:
# код
В этом примере мы указываем, что функция возвращает итератор целых чисел. Это простое изменение делает функцию более устойчивой в будущем, поскольку обеспечивает постоянный вывод.
Другим разработчикам достаточно будет взглянуть на объявление, чтобы увидеть, какой тип данных ожидать на выходе. И в отличие от простого использования документации, код выдаст ошибку, если это объявление будет нарушено.
Этот очень простой пример был взят отсюда. Воспользуйтесь приведённой ссылкой, чтобы лучше разобраться в теме.
Итог
Сложно перечислить все способы, которыми статическая типизация может избавить вас от мучений с кодом в будущем. Лучше понять это вам поможет документация к Mypy, которая содержит отличный раздел FAQ, где развёрнуто приведены все плюсы и минусы.
Если вы работаете в базе кода продакшена, где стабильность — это основа всего, то определённо стоит попробовать этот инструмент.
Секретное оружие #3:
Sonarlint: быстрый перехват ошибок и упрощённые функцииНа сегодняшний день каждый редактор обеспечивает определённый вид проверки ошибок или линтер. Он просматривает код, как правило, не выполняя его, и пытается угадать, что может пойти не так. Это называется статическим анализом кода.
Предустановленный линтер Python в VS CodeДинамический анализ кода фактически пытается выполнить/скомпилировать части кода, чтобы увидеть, работает ли он как следует. Однако делает он это на заднем плане автоматически. Вместо угадывания он действительно узнаёт, будет ли код работать и какие конкретные ошибки в нём могут быть.
SonarLint является динамическим анализатором кода в его лучшем виде и даже больше. Вот те возможности, за которые я его обожаю:
Закомментированный или невызыванный код
Я признаю свою вину в неудалении инструкций вывода, закомментированного кода и неиспользуемых функций по всей базе кода. Всё это служит мне предупреждением или напоминанием, помогая также проще ориентироваться и находить то, что нужно.
Угрозы безопасности
Огромная база данных постоянно обновляемых угроз безопасности предоставляется вашей базе кода в реальном времени, предупреждая о любых возможных её уязвимостях.
Угрозы безопасности относятся к той области, которую невозможно заучить, поэтому каждому следует использовать какой-либо инструмент для их отслеживания. SonarLint может стать отличной отправной точкой для выбора такого инструмента.
Никогда не выполняемый код
Несколько отличающийся от невызываемого кода, он предупредит меня, если я создам любые вычисления, которые могут иметь недостижимый результат. Как правило, их очень сложно обнаружить и в итоге можно провести много часов за отладкой. Поэтому такие предупреждения я тоже очень ценю.
Вот пример:
a = None
if a == None or not a or a:
this_will_always_get_called()
else:
# sonarlint напомнит вам, что эта строка никогда не выполняется
this_will_never_get_called()
Когнитивная сложность
Это удивительная тема, которой я мог бы посвятить отдельную статью. На самом деле по этой теме есть целая книга, правда недоступная в русском варианте.
Её суть в том, что SonarSource разработали математическую формулу, которая может вычислять сложность чтения/понимания кода.
Это не только невероятно полезный, но и очень удобный инструмент. Каждый раз, когда SonarLint просит меня “reduce cognitive complexity” (снизить когнитивную сложность), эта просьба сопровождается пояснением нарушенного правила (например, “too many nested if statements” (слишком много вложенных операторов if)).
Итог
Я считаю, что SonarLint более полезный, чем основные методы блокировки и линтинга. Я также убеждён в том, что он помогает мне писать более человеко-ориентированный код (между прочим, на Python).
SonarLint бесплатный, поэтому нет никаких причин откладывать его использование.
Заключение
Если вы сразу промотали до сюда, то должен вас предупредить, что вам будет сложно правильно использовать перечисленные ниже инструменты без базового понимания описанных выше возможностей.
Три секретных оружия:
Надеюсь, эти инструменты сослужат вам добрую службу. Лично я к ним сильно привязался.
Перевод статьи Preston Badeer: 3 Insane Secret Weapons for Python.
Комментарии