Комментарии 5
Какой опыт с Ruff был у вас?
выставляю настройку select = ["ALL"] а за ним в ignore дописываю, обычно со временем, меня не устраивающие
В целом - приемлемо :) Я считаю, что ”ALL” круто использовать в новых проектах. А в legacy-проектах, которые разрабатывались годами, это принесёт больше проблем из-за отработки множества правил. В то же время, если использовать ”ALL”, то будет расти список ignore, что уже не круто! И возможно ”ALL” будет медленнее отрабатывать, чем конкретный список правил.
Когда добавляю линтеры делаю так же.
Включаю всё и убираю, что в конкретном проекте пока стоит оставить.
А если одноразово сработало то можно и в коде отменить.
То, о чем написано в заголовке, совсем не раскрыто. А именно, опыт.
При этом не вижу причин не использовать ALL с пополнением ignore при необходимости.
Искал в этом статье блок, в котором оказалось бы про то, как внедряли в проекты с большой кодовой базой, какими проблемами столкнулись и как решили, но его нет 🤷 Ну раз уж нет, то поделюсь сам.
Подход 1. Хардкор
Включаем проверку всех правил и идем последовательно по всем ошибкам. В основном правим, какие-то правила добавляем в игнор. Проблема с таким подходом в том, что затрагивается весь код и процесс может занять больше количество времени. Плюс мы можем оставить баги. Плюс будет конфликт с другими ветками, если кто-то разрабатывается параллельно, что тоже может привести к багам. Из-за большого количества однотипных действий концентрация падает, как раз из-за этого в данном случае на простых действиях можно и словить ошибки.
Когда применимо? Когда проект не слишком большой и параллельно никто не занимается большими задачами.
Подход 2. Мягкий
Делал так при внедрении mypy, хорошо сработает и с ruff. Включаем все правила и пишем скрипт, который на основе текста с ошибками расставляет # noqa: XXX. И все. Заливаем в репозиторий. При конфликтах с другими ветками комментарии имеют более низкий приоритет, можно как просто скинуть noqa, либо честно решить конфликты. Далее при написании новой функциональности ruff уже работает. А при внесении правок в старый код потихоньку удалять noqa. Чтобы процесс пошел быстрее, можно создать отдельные задачи на конкретные модули, чтобы не было слишком много за раз, т.к. не хочется словить проблемы на пустом месте и не давать тестировщикам задачу протестить все приложение на глубоком уровне.
Спасибо за такой годный коммент! Да, действительно, мои текущие проекты являются отдельными сервисами, где нет огромной кодовой базы + есть возможность заниматься улучшениями, пока выполняются работы в других сервисах, не создавая конфликты в коде.
В своём кейсе я преследовал цель оперативно перейти на ruff при этом оставить старые правила проверки и добавить новые полезные для проекта правила. Поэтому выбрал пройти по хардкорному пути, но без ALL.
Также мне понравился ваш второй подход - креативно. Если в будущем будет возможность, попробую его!
Ruff: мой опыт выселения legacy-линтеров и повышения производительности кода