Зачем использовать линтер?
Как правильно назвать класс: MyClass или my_class? Думаем большинству очевидно, что правильней первый вариант. Но почему? Потому что в питоне так принято :)
Классы мы называем в CamelCase, функции и переменные в snake_case 🐍, а константы при помощи CAP_CASE.
Такое единообразие (консистентность) помогает при разработке: если вы увидели что-то в CAP_CASE, вы дважды подумаете, прежде чем изменить значение этой переменной.
В python3 нам повезло, что все пишут практически одинаково и здесь огромная заслуга PEP8 — документа с соглашениями о том, как надо писать код на python.
А в чем, собственно, проблема?
Представьте, что ваш коллега создал Merge Request, в котором совсем не соблюден codestyle: неверно названы переменные, нет отступов, избыточно длинные строки кода, и много чего еще — хотелось бы вам тратить время на замечания об этом? Конечно нет, ведь MR-ы созданы не для того, чтобы спорить о синтаксисе.
Можно создать текстовый документ, где были бы описаны все синтаксические правила для команды, с которыми необходимо периодически сверяться. Но даже так вы не защищены от ошибок. Ведь код пишут люди(пока что) , которые могут упустить какое-то из правил. Не говоря уже о том, что это просто муторно и скучно. Вот было бы автоматизированное решение…
Это решение и есть линтеры. Линтер — программа, которая проверяет наш код на соответствие правилам. Не только тем из них, что упомянуты выше, но и более сложным. Например, не слишком ли много локальных переменных в функции? А методов в классе? Кстати, такие проверки связаны с кошельком Миллера и реализованы, например, в wemake
А теперь представьте, что вам пришлось бы считать количество переменных во время MR
Надеемся, уже сейчас удалось продать вам идею об использовании линтеров. В начале с ними будет больно и это нормально. Зато спустя время ваш код станет проще читать и поддерживать, а ваша команда не будет тратить силы на споры о том, какие кавычки лучше: одинарные или двойные🙃
Для питона есть разные линтеры, которые различаются правилами, строгостью и типами проверок. Начать свое знакомство с ними можно, например, с этой статьи.
Кстати, на нашей программе Computer Vision Rocket, мы уделяем много внимания качеству кода: рассказываем как писать тесты, использовать линтер и автоматизировать эти проверки в gitlab CI. А еще мы внимательно ревьюим код студентов. Запишитесь на консультацию, мы ответим на любые ваши вопросы, покажем, как проходит обучение и code-review :)
Как правильно назвать класс: MyClass или my_class? Думаем большинству очевидно, что правильней первый вариант. Но почему? Потому что в питоне так принято :)
Классы мы называем в CamelCase, функции и переменные в snake_case 🐍, а константы при помощи CAP_CASE.
Такое единообразие (консистентность) помогает при разработке: если вы увидели что-то в CAP_CASE, вы дважды подумаете, прежде чем изменить значение этой переменной.
В python3 нам повезло, что все пишут практически одинаково и здесь огромная заслуга PEP8 — документа с соглашениями о том, как надо писать код на python.
А в чем, собственно, проблема?
Представьте, что ваш коллега создал Merge Request, в котором совсем не соблюден codestyle: неверно названы переменные, нет отступов, избыточно длинные строки кода, и много чего еще — хотелось бы вам тратить время на замечания об этом? Конечно нет, ведь MR-ы созданы не для того, чтобы спорить о синтаксисе.
Можно создать текстовый документ, где были бы описаны все синтаксические правила для команды, с которыми необходимо периодически сверяться. Но даже так вы не защищены от ошибок. Ведь код пишут люди
Это решение и есть линтеры. Линтер — программа, которая проверяет наш код на соответствие правилам. Не только тем из них, что упомянуты выше, но и более сложным. Например, не слишком ли много локальных переменных в функции? А методов в классе? Кстати, такие проверки связаны с кошельком Миллера и реализованы, например, в wemake
А теперь представьте, что вам пришлось бы считать количество переменных во время MR
Надеемся, уже сейчас удалось продать вам идею об использовании линтеров. В начале с ними будет больно и это нормально. Зато спустя время ваш код станет проще читать и поддерживать, а ваша команда не будет тратить силы на споры о том, какие кавычки лучше: одинарные или двойные🙃
Для питона есть разные линтеры, которые различаются правилами, строгостью и типами проверок. Начать свое знакомство с ними можно, например, с этой статьи.
Кстати, на нашей программе Computer Vision Rocket, мы уделяем много внимания качеству кода: рассказываем как писать тесты, использовать линтер и автоматизировать эти проверки в gitlab CI. А еще мы внимательно ревьюим код студентов. Запишитесь на консультацию, мы ответим на любые ваши вопросы, покажем, как проходит обучение и code-review :)