Комментарии 8
15 лет... Ничего себе...
Очень бы хотелось увидеть возможность автоматического исправления найденных PVS-Studio ошибок. Конечно это не всегда можно реализовать, но есть целый класс ошибок, о которых можно не только оповещать, но и смело править. Как это делает один из инструментов похожего толка, только для JavaScript.
15 лет, это сильно, желаю вам, что бы задор не утихал, а разгорался с новой мощью, и нас продолжали радовать новые приключения статического анализатора.
По поводу автоматических правок. Таких планов нет. Автоматическими изменениями кода занимаются инструменты, осуществляющие рефакторинг или форматирование кода. Мы не развиваем инструмент в этом направлении. Мы сосредоточены именно на поиске потенциальных ошибок и потенциальных уязвимостей.
Говоря о правке ошибок, это возможно только для очень простых случаев. В результате, эта функциональность будет столь ограничена, что лучше вообще её не делать. Тем более всё равно слишком велик риск неправильного изменения кода и человек обязан участвовать в этом процессе.
Подробнее эта тема раскрыта в статье "Почему PVS-Studio не предлагает автоматические правки кода".
Благодарю за развёрнутый ответ.
Автоматическими изменениями кода занимаются инструменты, осуществляющие рефакторинг или форматирование кода.
Рефакторинг - это плановое изменения кода по обозначенному маршруту в рамках конкретного проекта.
Форматирование - это визуальное оформление кода: отступы и точки с запятыми.
Я же говорю об автоматическом исправлении проблемных мест в соответствии с лучшими правилами построения качественного кода.
Пример из статьи очень не плохой кандидат для автоматизации:
Говоря о правке ошибок, это возможно только для очень простых случаев. В результате, эта функциональность будет столь ограничена, что лучше вообще её не делать. Тем более всё равно слишком велик риск неправильного изменения кода и человек обязан участвовать в этом процессе.
Тут я с вами не соглашусь абсолютно. И вот почему, давайте разбираться.
Говоря о правке ошибок, это возможно только для очень простых случаев.
Какие случаи вы считаете простыми? Наверняка те, с которыми научились работать, и те которые начали автоматизировать. Начало в любом случае будет простым. Но из этого простого решения, постепенно начнут складыватся более сложные. К примеру в ?Putout есть возможность перевода CommonJS в ESM и наоборот.
В результате, эта функциональность будет столь ограничена, что лучше вообще её не делать.
Тут вы делаете вывод из собственного утверждения. А ведь простой функционал - это быстрый MVP и прямая польза.
Тем более всё равно слишком велик риск неправильного изменения кода
Риск есть всегда, однако есть и риск успешного приминения трансформаций кода, и тогда ошибки можно будет не только найти но и применить исправление. А неправильные изменения кода должны ловить тесты и компилятор.
> и человек обязан участвовать в этом процессе.
В этом я с вами не буду спорить, конечно за человеком остаётся решение. Но чем больше щепетильной монотонной работы передаётся машине, тем больше времени человек может посвящать творчеству и архитектурным решениям. Да, неплохо присматривать за результатом, но одно дело проверять результат, и совсем другое его выдавать.
PVS — инструмент, продаваемый бизнесу, а не одиночкам.
Если какому-нибудь стажёру дадут задание «разберись тут с предупреждениями», и он не сможет понять суть проблемы (а спрашивать у старших товарищей постесняется), и примет предлагаемое «исправление», негатив останется от инструмента, а не от стажёра.
Что нового появилось в PVS-Studio в 2021 году