Pylint visual studio code как пользоваться

Обновлено: 03.07.2024

В сообществе Python, как и в любой другой группе людей, существует некое коллективное знание. Множество людей прошлось по всем возможным граблям и получило опыт через набитые шишки. Затем через какое-то время, благодаря выступлениям на конференциях, официальным заявлениям, документам, статьям в блогах, код-ревью и личному общению, это знание стало коллективным. Теперь мы просто называем его “хорошими практиками”.

К таким хорошим практикам можно отнести, например, следующие.

Форматировать код по PEP8 — если этого не делать, то другим людям будет намного сложнее понимать ваш код; в плохо оформленном коде сложнее увидеть суть, потому что мозг постоянно отвлекается на не несущие смысловой нагрузки особенности оформления.
Не допускать объявленных, но неиспользуемых переменных/функций/импортов — опять же, это усложняет восприятие кода; читателю потребуется потратить время на то, чтобы осознать, что вот на эту сущность обращать внимания не нужно.
Писать короткие функции — слишком сложные функции с большим количеством ветвлений и циклов тяжело понимать.
Не использовать изменяемый объект в качестве значения аргумента функции по умолчанию — иначе в результате можно получить очень неожиданные эффекты.

Соблюдать (и даже просто помнить) все хорошие практики — не самая простая задача. Зачастую люди плохо справляются с тем, чтобы отсчитывать пробелы и контролировать переменные, и вообще склонны допускать ошибки по невнимательности. Таковы люди, ничего не поделаешь. Машины, наоборот, прекрасно справляются с такими хорошо определёнными задачами, поэтому появились инструменты, которые контролируют следование хорошим практикам.

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

В этом посте я рассмотрю два самых популярных линтера для Python:

Термин “lint” впервые начал использоваться в таком значении в 1979 году. Так называлась программа для статического анализа кода на C, которая предупреждала об использовании непортабельных на другие архитектуры языковых конструкций. С тех пор “линтерами” называют любые статические анализаторы кода, которые помогают находить распространённые ошибки, делать его однообразным и более читаемым. А названо оно "lint" в честь вот такой штуки:

flake8

flake8 — это утилита-комбайн, которая органично объединяет в себе несколько других анализаторов кода ( pycodestyle , pyflakes и mccabe ), а также имеет огромную экосистему плагинов, которые могут добавить к стандартной поставке ещё кучу различных проверок. На данный момент, это самый популярный линтер для Python-кода. Кроме того, он предельно прост в настройке и использовании.

Установка

flake8 устанавливается, как и любой другой Python-пакет, через pip . Внутри виртуального окружения проекта выполните:

Если вы пользуетесь pipenv , то flake8 нужно устанавливать как dev-зависимость (ведь для работы программы линтер не нужен, он нужен только для разработчика):

Разные помощники в написании классного кода нас просто окружают, линтеры, тайпчекеры, утилиты для поиска уязвимостей, всё с нами. Мы привыкли и используем не вдаваясь в детали, как «черный ящик». Например, мало кто разбирается в принципах работы Pylint — одного из таких незаменимых инструментов для оптимизации и улучшения кода на Python.

А вот Максим Мазаев знает, насколько важно понимать свои инструменты, и нам рассказал на Moscow Python Conf++. На реальных примерах показал, как знание внутреннего устройства Pylint и его плагинов помогло уменьшить время code review, улучшить качество кода и вообще повысить эффективность разработки. Ниже расшифровка-инструкция.

Зачем нам Pylint?

Если вы его уже используете, то может возникнуть вопрос: «Зачем знать, что внутри у Pylint, чем эти знания могут помочь?»

Долгое время и в ЦИАН именно так работали с Pylint, с небольшими дополнениями: меняли конфигурации, убирали лишние правила, увеличили максимальную длину строки.

Но в какой-то момент столкнулись с проблемой, для решения которой, пришлось копнуть глубоко внутрь Pylint и разобраться, как он работает. Что это за проблема и как ее решили, читайте дальше.

О спикере: Максим Мазаев (backslash), 5 лет в разработке, работает в ЦИАН. Глубоко изучает Python, асинхронность и функциональное программирование.

О ЦИАН

Большинство считает, что ЦИАН — это агентство недвижимости с риелторами и очень удивляются, когда узнают, что вместо риэлторов у нас работают программисты.

Мы — техническая компания, в которой нет риелторов, зато очень много программистов.

1 млн. уникальных пользователей в сутки.
Самая крупная доска объявлений о продаже и аренде недвижимости в Москве и Санкт-Петербурге. В 2018 году вышли на федеральный уровень и работаем по всей России.
Почти 100 человек в команде разработки, из которых 30 ежедневно пишут код на Python.

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

Code review

Code review в ЦИАН проходит в два этапа:

Проблемы code review

Pull request может не пройти code review из-за:

ошибок в бизнес-логике, когда разработчик неэффективно или неправильно решил задачу;
проблем со стилем кода.

Все кто пишет на Python знают, что существует руководство по написанию кода РЕР-8. Как любой стандарт, PEP-8 довольно общий и нам, как разработчикам, этого недостаточно. Стандарт хочется в одних местах конкретизировать, а в других расширить.

Поэтому мы придумали свои внутренние договоренности о том, как код должен выглядеть и работать, и назвали их «Decline Cian Proposals».

«Decline Cian Proposals» — набор правил, сейчас их примерно 15. Каждое из этих правил — основание, чтобы pull request был отклонен и отправлен на доработку.

Что мешает продуктивному code review?

С нашими внутренними правилами есть одна проблема — линтер не знает про них, и было бы странно, если бы знал — они же внутренние.

Разработчику, который выполняет задачу, нужно всегда помнить и держать правила в голове. Если он забудет одно из правил, то в процессе code review проверяющие укажут на проблему, задача отправится на доработку и время релиза задачи увеличится. После доработки и исправления ошибок, проверяющим нужно вспомнить, что же было в задаче, переключать контекст.

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

От этой проблемы нам бы хотелось избавиться.

А не написать ли нам свой линтер?

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

На самом деле нет. Идея дурацкая, потому что у нас уже используется Pylint. Это удобный линтер, нравится разработчикам и встроен во все процессы: запускается в Jenkins, генерирует красивые отчеты, которые полностью устраивают и в виде комментариев приезжают в pull request. Все отлично, второй линтер не нужен.

Так как решить проблему, если свой линтер мы писать не хотим?

Написать плагин для Pylint

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

Рассмотрим два примера подобных чекеров.

Пример № 1

В какой-то момент обнаружилось, что в коде много комментариев вида «TODO» — обещаний отрефакторить, удалить ненужный код или переписать его красиво, но не сейчас, а позже. С подобными комментариями есть проблема — они совершенно ни к чему не обязывают.

Проблема

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

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

Решение: пишем свой чекер для Pylint

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

Нам нужно найти все комментарии вида TODO и убедиться, что в каждом из них есть ссылка на задачу в Jira. Давайте писать.

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

В нашем случае это IRawChecker — так называемый «сырой» чекер.

«Сырой» чекер итерируется по строкам файла и над строкой может выполнить определенное действие. В нашем случае в каждой строке чекер будет искать нечто похожее на комментарий и ссылку на задачу.

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

Следующий шаг — определить метод, который называется process_module.

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

В модуль передается параметр node. В данном случае неважно, что это такое и какого он типа, важно только помнить, что у node есть метод stream, который возвращает файл построчно.

По файлу можно пройтись и для каждой строчки проверить наличие комментариев и ссылки на задачу. Если комментарий есть, а ссылки нет, то выбросить предупреждение вида ’issue-code-in-todo’ с кодом чекера и номером строки. Алгоритм достаточно простой.

Регистрируем чекер, чтобы Pylint о нем знал. Это делается функцией register:

В функцию приходит экземпляр Pylint.
В нём вызывается метод register_checker.
В метод передаем сам чекер.

Для теста запускаем Pylint, передаем в него модуль, с помощью параметра load-plugins передаем чекер, и внутри линтера запускаем две фазы.

Фаза 1. Инициализация плагинов

Фаза 2. Разбираем пул чекеров

После фазы 1 остается целый список чекеров разных типов:

Из списка выделяем те, что относятся к интерфейсу «сырого» чекера: смотрим какие чекеры имплементируют интерфейс IRawChecker и берем их себе.

Для каждого отобранного чекера вызываем метод checker.process_module(module), и запускаем проверку.

Результат

Снова запускаем чекер на тестовом файле:

Проблема решена и теперь в процессе code review разработчикам не нужно сканировать код глазами, находить комментарии, писать автору кода напоминание, что есть договоренность и желательно оставить ссылку. Всё происходит автоматизировано и code review проходит чуть быстрее.

Пример № 2. keyword-arguments

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

Проблема

Например, у нас есть функция:

В коде есть sale и True и непонятно, что они означают. Гораздо удобнее, когда функции, в которых много аргументов, вызывались бы только с именованными аргументами:

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

«Сырой» чекер, использовавшийся в предыдущем примере, для такого случая написать очень сложно. Можно добавить супер-сложные регулярные выражения, но такой код тяжело читать. Хорошо, что Pylint дает возможность написать другой тип чекера на основе абстрактного синтаксического дерева AST, его и будем использовать.

Лирическое отступление про AST

AST или абстрактное синтаксическое дерево — это представление кода в виде дерева, где вершина — операнды, а листья — операторы.

Например, вызов функции, где есть один позиционный аргумент и два именованных, трансформируется в абстрактное дерево:

Здесь есть вершина с типом Call и она имеет:

атрибуты функции с названием func;
список позиционных аргументов args, где есть нода с типом Const и значением 112;
список именованных аргументов Keywords.

Найти в модуле все ноды с типом Call (вызов функции).
Посчитать общее количество аргументов, которые принимает функция.
Если аргументов больше 2, то убедиться, что в ноде отсутствуют позиционные аргументы.
Если есть позиционные аргументы, то показать предупреждение.

С точки зрения Pylint, чекер на основе AST — это класс, который наследуется от класса базового чекера и имплементирует интерфейс IAstroidChecker:

Следующий шаг — определяется метод visit_call:

Метод не обязательно должен так называться. Самое главное в нем — префикс visit_, а дальше идет имя вершины, которая нас интересует, с маленькой буквы.

AST-парсер ходит по дереву и для каждой вершины смотрит, определены ли у чекера интерфейс visit_<Имя>.
Если да, то вызывает его.
Рекурсивно проходит по всем ее детям.
При уходе с ноды вызывает метод lеаvе_<Имя>.

Регистрируем чекер, как в предыдущем примере: передаем экземпляр Pylint, вызываем register_checker, передавая сам чекер и запускаем.

Это пример вызова тестовой функции, где есть 3 аргумента и только один из них именованный:

Это функция, которая потенциально вызывается неправильно с нашей точки зрения. Запускаем Pylint.

Фаза 1 инициализации плагинов полностью повторяется, как и в предыдущем примере.

Фаза 2. Разбор модуля на AST

Код разбирается в AST-дерево. Разбор выполняет библиотека Astroid.

Почему Astroid, а не AST (stdlib)

Astroid внутри себя использует не стандартный модуль Python AST, а типизированный AST-парсер typed_ast, отличающийся тем, что поддерживает тайпхинты из РЕР 484. Typed_ast — это ответвление AST, форк, который развивается параллельно. Что интересно, там присутствуют те же баги, что в AST, и чинятся параллельно.

Раньше Astroid использовал стандартный AST-модуль, в котором можно было столкнуться с проблемой использования тайпхинтов, определенных в комментариях, которые используются во втором Python. Если проверить такой код через Pylint, то до определенного момента он ругался на неиспользованный импорт, потому что импортированный класс Entity присутствует только в комментарии.

В какой-то момент на GitHub к Astroid пришел Гвидо Ван Россум и сказал: «Ребята, у вас есть Pylint, который ругается на такие кейсы, а у нас есть типизированный AST-парсер, который поддерживает это все. Давайте дружить!»

Работа закипела! Прошло 2 года, этой весной Pylint уже перешел на типизированный AST-парсер и перестал ругаться на такие вещи. Импорты для тайпхинтов больше не помечаются как неиспользуемые.

Astroid использует AST-парсер, чтобы разобрать код на дерево, а потом при сборке делает некоторые интересные вещи. Например, если вы используете import *, то он импортирует все, что по звездочке, и добавит в locals, чтобы предотвратить ошибки с неиспользованными импортами.

Transform plugins используются в случаях, когда есть какие-то сложные модели, основанные на мета-классах, когда все атрибуты генерируются динамически. В этом случае Astroid очень сложно понять, что подразумевается. При проверке Pylint будет ругаться, что в моделях нет такого атрибута, когда к нему обращаются, а с помощью Transform plugins можно решить проблему:

Помочь Astroid модифицировать абстрактное дерево и разобраться в динамической природе Python.
Дополнить AST полезной информацией.

Фаза 3. Разбираем пул чекеров

Возвращаемся к чекеру. У нас снова есть список чекеров, из которых мы находим те, что имплементируют интерфейс AST checker.

Фаза 4. Разбираем чекеры по типам нод

Дальше у каждого чекера находим методы, они могут быть двух типов:

То же самое с leave-методами: ключ в виде имени ноды, список чекеров, которым интересен факт выхода с этой ноды.

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

Проблема решена. Теперь программистам на code review не нужно считать аргументы у функции, за них это сделает линтер. Мы сэкономили свое время, время на code review и задачи быстрее проходят в продакшн.

А тесты написать?

Pylint позволяет провести юнит-тестирование чекеров и это очень просто. С точки зрения линтера, тест-чекер выглядит как класс, который наследуется от абстрактного CheckerTestCase. В нем необходимо указать тот чекер, который проверяем.

Шаг 1. Создаем тестовую AST-ноду из той части кода, что проверяем.

TokenChecker

Есть еще один тип чекера, который называется TokenChecker. Он работает по принципу лексического анализатора. В Python есть модуль tokenize, который выполняет работу лексического сканера и разбивает код на список токенов. Это может выглядеть примерно так:

Названия переменных, функций и ключевые слова становятся токенами с типом NAME, а разделители, скобочки, двоеточия — токенами с типом OP. Кроме этого есть отдельные токены для индентации, перевода строки и обратного перевода.

Как Pylint работает с TokenChecker:

Проверяемый модуль токенизируется.
Огромный список токенов передается всем чекерам, которые имплементируют ITokenChecker и вызывается метод рrocess_tokens (tokens).

Проверка правописания. Например, можно взять все токены с типом text и посмотреть на лексическую грамотность, проверить слова из списков стоп-слов и т.д.
Проверка отступов, пробелов.
Работа со строками. Например, можно проверить, что в Python 3 не используются юникод-литералы или убедиться, что в байтовой строке присутствуют только ASCI-символы.

Выводы

У нас была проблема с code review. Разработчики выполняли работу линтера, тратили свое время на бессмысленное сканирование кода и информирование автора об ошибках. С Pylint мы:

Переложили рутинные проверки на линтер, имплементировали внутренние соглашения в нем.
Увеличили скорость и качество code review.
Сократили количество отклоненных pull request, а время прохождения задач в продакшн стало меньше.

Подробнее узнать про Pylint и то, как писать для него чекеры, можно в официальной документации, но в плане написания чекеров она достаточно бедная. Например, про TokenChecker там присутствует только упоминание, что он есть, но нет про то, как написать сам чекер. Больше информации есть в исходниках Pylint на GitHub. Можно посмотреть, какие есть чекеры в стандартной поставке и вдохновиться на написание своего.

Знание внутреннего устройства Pylint экономит человеко-часы, упрощает
работу и улучшает код. Экономьте свое время, пишите хороший код и
пользуйтесь линтерами.

Следующая конференция Moscow Python Conf ++ состоится 5 апреля 2019 г. и уже сейчас можно забронировать early birf билет. А еще лучше будет собраться с мыслями и подать заявку на доклад, тогда посещение будет бесплатным, а бонусом пойдут приятные плюшки, включая коучинг по изготовлению доклада.

Наша конференция — площадка для встречи с единомышленниками, двигателями индустрии, для общения и обсуждения любимых Python-разработчиками вещей: backend и web, сбор и обработка данных, AI/ML, тестирование, IoT. Как она прошла осенью посмотрите в видеоотчете на нашем канале Python Channel и подпишитесь на канал — скоро выложим лучшие доклады с конференции в свободный доступ.

VS Code от Microsoft – легкий и удобный редактор кода, доступный на всех платформах и невероятно гибкий. Это отличный выбор для программирования на Python.

В этой статье мы рассмотрим способы установки и настройки максимально эффективной рабочей среды для разработки.

Статья предназначена для программистов, уже имеющих опыт работы с Python и установивших на свою рабочую машину интерпретатор этого языка программирования (Python 2.7, Python 3.6/3.7, Anaconda или другой дистрибутив).

Установка Python – дело несложное: здесь вы найдете подробное пошаговое руководство для всех популярных ОС. Помните, что в разных операционных системах интерфейс VS Code может немного различаться.

Установка и настройка Visual Studio Code для разработки на Python

Сразу же отметим, что VS Code не имеет практически ничего общего с его знаменитым тезкой Visual Studio.

Редактор очень легко установить на любую платформу: на официальном сайте есть подробные инструкции для Windows, Mac и Linux.

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

VS Code + Python

С 2018 года есть расширение для Python. Наблюдать за развитием отношений этой пары можно в блоге Microsoft.

Основные возможности редактора:

Поддержка Python 3.4 и выше, а также Python 2.7
Автоматическое дополнение кода с помощью IntelliSense
Автоматическое использование conda и виртуальных сред
Редактирование кода в средах Jupyter и Jupyter Notebooks

А вот пара полезных подборок для прокачки Python-скиллов:

В редакторе есть и полезные фичи, не связанные напрямую с языком:

Настраиваемые темы оформления для множества языков, включая русский

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

Автосохранение (File - Auto Save) и удобная настройка его задержки. между различными устройствами с помощью GitHub.
Удобная работа с Docker.

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

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

Файлы конфигурации

В Visual Studio Code вы легко можете настроить все под себя. Здесь есть параметры пользователя, которые являются глобальными, и параметры рабочей области – локальные для конкретных папок или проектов. Локальные настройки сохраняются в виде .json-файлов в папке .vscode.

Новый проект на Python

Чтобы открыть новый файл, нужно зайти в меню Файл и выбрать пункт Создать или нажать горячую комбинацию клавиш Ctrl+N .

Еще в редакторе есть полезная палитра команд, которую можно вызвать сочетанием Ctrl+Shift+P . Для создания нового файла введите в появившемся поле File: New File и нажмите Enter .

Какой бы способ вы ни выбрали, перед вами должно открыться вот такое окно:

Здесь уже можно вводить код вашей программы.

Начинаем кодить

Для демонстрации возможностей редактора напишем "Решето Эратосфена" – известный алгоритм для нахождения простых чисел до некоторого предела. Начнем кодить:

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

Подождите, что-то не так. Почему-то VS Code не выделяет ключевые слова языка, не дополняет, не форматирует и вообще ничего полезного не делает. Зачем он вообще такой нужен?

Без паники! Просто сейчас редактор не знает, с каким файлом он имеет дело. Смотрите, у него еще нет названия и расширения – только какое-то неопределенное Untitled-1. А в правом нижнем углу написано Plain Text (простой текст).

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

меню: Файл - Сохранить
горячая комбинация: Ctrl+S
палитра команд: File: Save File

Дайте файлу имя sieve.py.

Теперь редактор понял, что имеет дело с кодом на Python, и исправился:

Так гораздо лучше! В правом нижнем углу появилась надпись Python, значит все работает правильно.

Если на вашем компьютере установлено несколько интерпретаторов языка (Python 2.7, Python 3.x или Anaconda), вы можете выбирать нужный. Для этого кликните на индикаторе языка (внизу в левой части экрана) или наберите в палитре команд Python: Select Interpreter .

По умолчанию VS Code поддерживает форматирование с использованием pep8, но вы можете выбрать black или yapf, если хотите.

Допишем код алгоритма:

Если вы будете вводить его вручную (без copy-paste), то сможете увидеть IntelliSense редактора в действии.

VS Code автоматически делает отступы перед операторами for и if , добавляет закрывающие скобки и предлагает варианты завершения слов.

Запуск программы

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

Теперь, когда код завершен, его можно запустить. Для этого не нужно выходить из редактора: Visual Studio Code может запускать эту программу непосредственно в Редакторе. Сохраните файл (с помощью Ctrl+S ), затем щелкните правой кнопкой мыши в окне редактора и выберите пункт Запустить файл Python в терминале.

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

Линтинг кода

flake8
mypy
pydocstyle
pep8
prospector
pyllama
bandit

Подробные сведения о настройке каждого из них вы можете найти здесь.

Обратите внимание, что линтер настраивается для конкретной рабочей области, а не глобально.

Редактирование существующего проекта

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

С редактором можно работать прямо из консоли, открывая и создавая файлы простой командой code filename.py .

Посмотрим, на что способен VS Code на примере уже готового проекта. Это библиотека для анализа уравнений, основанная на "алгоритме маневровой станции" (shunting-yard algorithm) Дийкстры. Вы можете клонировать этот репозиторий, чтобы начать работу.

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

VS Code умеет работать с различными средами: virtualenv, pipenv или conda.

Также вы можете открыть папку прямо из интерфейса редактора:

меню: Файл - Открыть папку
горячие клавиши: Ctrl+K , Ctrl+O
из палитры команд: File: Open Folder

Вот так выглядит открытый проект:

По умолчанию при открытии папки VS Code также открывает файлы, с которыми вы работали в последний раз. Это поведение можно изменить.

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

Тестирование

Грамотное программирование на Python помимо собственно написания кода включает также его тестирование.

Visual Studio Code умеет автоматически распознавать тесты в unittest, pytest или Nose. В нашем проекте есть модульный тест, который можно использовать для примера.

Чтобы запустить существующие тесты, из любого файла Python вызовите правой кнопкой мыши контекстное меню и выберите пункт Запустить текущий тестовый файл.

Нужно будет указать используемый для тестирования фреймворк, путь поиска и шаблон для имени файлов тестов. Эти настройки сохраняются как параметры рабочей области в локальном файле .vscode/settings.json. Для нашего проекта нужно выбрать unittest, текущую папку и шаблон *_test.py.

Теперь можно запустить все тесты, кликнув на Run Tests в строке состояния или из палитры команд.

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

Результаты тестов отображаются во вкладке Output (раздел Python Test Log выпадающего меню).

Посмотрите также:

Отладка кода

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

Автоматическое отслеживание переменных
Отслеживание выражений
Точки прерывания
Инспекция стека вызовов

Все эти данные можно найти во вкладке Debug левой панели.

Отладчик может управлять приложениями Python, запущенными во встроенной консоли или внешнем терминале. Он может подключаться к уже запущенным экземплярам Python и даже отлаживать приложения Django и Flask.

Отладить программу на Python так же просто, как запустить отладчик с помощью F5 . Используйте F10 и F11 для перехода к следующей функции и для захода в текущую функцию. Shift+F5 – выход из отладчика. Точки останова задаются с помощью клавиши F9 или щелчком мыши в левом поле окна редактора.

Перед началом отладки более сложных проектов, включая приложения Django или Flask, необходимо настроить и выбрать конфигурацию отладки. Сделать это очень просто. Во вкладке Debug найдите раскрывающееся меню Configuration и нажмите Add Configuration:

VS Code создаст и откроет файл .vscode/launch.json, в котором можно настроить конфигурации Python, а также отладку приложений.

Вы даже можете выполнять удаленную отладку и дебажить шаблоны Jinja и Django. Закройте launch.json и выберите нужную конфигурацию приложения из раскрывающегося списка.

Посмотрите также:

Интеграция с Git

В VS Code прямо из коробки есть встроенная поддержка управления версиями. По умолчанию подключен Git и GitHub, но вы можете установить поддержку других систем. Все работа происходит во вкладке Source Control левого меню:

Если в проекте есть папка .git, весь спектр функций Git/GitHub включается автоматически. Вы можете:

Все эти функции доступны прямо из пользовательского интерфейса:

VS Code также распознает изменения, внесенные вне редактора.

Visual Studio Code + Python = довольный разработчик

Visual Studio Code – один из самых крутых редакторов кода и замечательный инструмент для разработки. Редактор из коробки предлагает множество полезных возможностей и гибко подстраивается под все ваши потребности. Программирование на Python становится проще и эффективнее.

А какой редактор (или полноценную IDE) для разработки на Python используете вы?

Сегодня немного о моих мытарствах с VS Code и его настройкой для нормальной работы с Python разных версий. Сразу оговорюсь, что всё это настраивалось под меня, опыта у меня мало и вообще это большей частью “for fun”.

Редактор правда очень крутой, мощный (“навороченнее” какого-нибудь sublime text) и при этом очень лёгкий (запускается и работает шустрее PyCharm’a). Во всяком случае на мой неопытный взгляд (хотя авторитетные бобры тоже используют). Предполагается, что Python (2.x или 3.x, не важно) у вас уже установлен.

Итак.

После установки он попросит установить pylint, но это не сложно сделать прямо здесь же из консоли:

На этом как бы и всё, формальная часть выполнена. Но. Сегодня мне понадобилось протестить один и тот же код на работоспособность в Python 2.7 и 3.6. В Ubuntu проблем не возникало: жмём Ctrl+Shift+P, ищем в появившемся меню “Python: Select Workspace Enterpreter” и выбираем нужное из списка. В Win10 почему-то это не сработало так просто: хотя на компьютере точно установлены 2.7, 3.5 и 3.6. в списке только 2.7. Как добавить элементы в этот список я не нашёл, но нашёл способ изменить и дебагер и текущую используемую версию python в файлах настроек.

Дебагер.

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

Нажимаете “Добавить конфигурацию” и изменяете добавившийся блок.

В этом блоке вам нужно изменить 2 строки: “name” (имя конфигурации)и “pythonPath” (путь до python.exe нужной версии). Не забудьте экранировать бэк-слэши:

Текущая версия интерпретатора.

Можно изменить в настройках приложения (файл settings.json). Нужно добавить следующее (Python 3.6):

Сохраняем настройки и теперь ваши скрипты будут исполняться интерпритатором Python 3.6.

Git

По дефолту в git пытается выгрузиться совершенно там ненужная папка .vscode, которая хранит разного рода служебную инфу. Чтобы этого не происходило создайте в корне проекта файлик .gitignore и добавьте в него следующее содержимое (.gitignore — чтобы игнорировался сам этот файл, да):

Приятные плюшки

Всё, указанное ниже, прописывается в файле settings.json

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

Очень бывает удобно видеть количество пробелов перед строкой (особенно в python) и лишние пробелы между символами/словами:

Читайте также: