Что общего между Putout и Rulegurd?

Недавно наткнулся на статью про статический анализатор Ruleguard и хотел написать к ней комментарий, но получилась статья.

Интересно, что похожие идеи могут в одно время прийти разным людям, пишущим на разных языках. Я работаю над статическим анализатором Putout, и обратил внимание, что синтаксис, используемый в этих двух инструментах очень похож. В статье будет много кода на JavaScript и Go, языке который я совсем не знаю, тем не менее схожесть используемых подходов, не могла не вызвать у меня интерес.

А в конце вас ждет опрос :).

Время жизни

Рассмотрим хронологию:

• 30.11.2018 — первый коммит Putout
• 12.12.2019 — первый коммит Ruleguard

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

Правила

Сравним примеры правила, которое упрощает выражение !!x до x.
Для ruleguard, код будет выглядеть таким образом:

package gorules  import "github.com/quasilyte/go-ruleguard/dsl/fluent"  func simplify(m fluent.Matcher) {     m.Match(`!!$x`)      .Suggest(`$x`)      .Report(`can simplify !!$x to $x`) }

А вот (упрощенный и адаптированный) пример правила putout remove-double-negations:

module.exports.report = () => 'can simplify !!x to x'; module.exports.replace = () => ({     '!!__x': '__x' });

Обратите внимание, что ruleguard, использует $x для обозначения переменных (интересно разворачивает ли функция Report переменную $x), а putout, для той же цели, использует двойное нижнее подчеркивание __x. Почему в putout не был выбран символ $? Одна из причин это наличие валидных, (хоть и не часто) используемых идентификаторов в популярных библиотеках, а еще похожесть на один очень практичный язык программирования, где все переменные начинаются с этого символа :), а так же выразительность двойного подчеркивания. Тут список всех поддерживаемых переменных.

Судя по всему, автор ruleguard тоже изначально использовал ‘__’, но в какой-то момент отдал предпочтение знаку доллара, который лаконичнее.

Работа с AST

Вначале правила putout, писались таким образом, что AST парсилось отдельно каждым плагином, таким образом:

// возвращаем ошибку соответствующую каждому из найденых узлов module.exports.report = () => 'Unexpected "debugger" statement';  // ищем узлы, содержащией debugger с помощью паттерна Visitor module.exports.find = (ast, {traverse}) => {     const places = [];      traverse(ast, {         DebuggerStatement(path) {             places.push(path);         }     });      return places; };  // удаляем код, найденный в предыдущем шаге module.exports.fix = (path) => {     path.remove(); };

Как верно заметил Alternator:

Каждый плагин выполняет свой traverse, что медленнее чем один комбинированный traverse, выполненный ядром.

Поэтому, обход всего AST (по возможности) выполняется единожды, поочередно заходя в нужные плагины (что позволяет 60-ти плагинам отрабатывать за вменяемое время), которые в самом простом виде могут выглядеть так:

module.exports.report = () => 'Unexpected "debugger" statement'; module.exports.replace = () => ({     'debugger': '', });

Однако в ruleguard, судя по всему, каждый раз при вызове Match выполняется обход всего дерева, в поисках нужного места кода, quasilyte, это так, или я не до конца понимаю механизм?

Ели это так, то:

• да, это медленно
• это не дает контекста

Дело в том, что при разработке плагинов гораздо чаще появляется необходимость детально исследовать найденные узлы, как (и сколько раз) переменные используются, где они объявлены (и объявлены ли), в каком окружении используются. К примеру в плагине convert-for-in-to-for-of, который делает следующее:

-for (const name in object) { -   if (object.hasOwnProperty(name)) { +for (const name of Object.keys(object)) {     console.log(a); -   } }

Работает таким образом:

const {     generate,     operator, } = require('putout');  const {     contains,     getTemplateValues, } = operator;  module.exports.report = () => `for-of should be used instead of for-in`;  // отфильтровуем необходимые данные // важно что бы for-in имел `hasOwnProperty` // иначе реализация for-of будет работать иначе module.exports.match = () => ({     'for (__a in __b) __body': ({__a, __b, __body}) => {         const declaration = getTemplateValues(__a, 'var __a');         const {name} = declaration.__a;          return contains(__body, [             `if (${__b.name}.hasOwnProperty(${name})) __body`,         ]);     }, });  // выполняем замену, если функция прошла фильтр module.exports.replace = () => ({     'for (__a in __b) __body': ({__b, __body}) => {         const [first] = __body.body;         const condition = getTemplateValues(first, 'if (__b.hasOwnProperty(__a)) __body');         const {code} = generate(condition.__body);          return `for (const ${condition.__a.name} of Object.keys(${__b.name})) ${code}`;     }, });

Конечно, в Go нет таких конструкций (там другие не менее полезные :)), однако необходимость в том, что бы знать больше об узлах, которые обрабатываются остается прежней, и мне пока не понятно как это можно сделать с помощью функции Match из ruleguard. На помощь могут прийти фильтры, но они в основном связаны с типами. Возможно я просто пока не понял, как эту функциональность можно расширить, либо этот функционал (на что я надеюсь) появится в новых версиях Ruleguard.

Плагины

Putout поддерживает 5 видов подгрузки плагинов:

• @putout/plugin-name — core-плагины из папки node_modules
• putout-plugin-name — userland-плагины из node_modules
• ~/.putout — codemods, которые нужны для текущих проектов
• с помощью флага --rulesdir, к примеру, из папки текущего проекта
• с помощью параметра командной строки -t, --transform

По поводу ruleguard quasilyte говорит следующее:

Правила ruleguard подгружаются на старте, из специального gorules файла, декларативно описывающего паттерны кода, на которые стоит выдавать предупреждения. Этот файл может свободно редактироваться пользователями ruleguard.

И в этом есть плюс и минус:

• плюс в том, что можно правила обработки проекта записать в специальный файл, писать туда правила и переиспользовать их для нового кода;
• минус — в невозможности переиспользования написанного кода для других проектов (файл необходимо копировать, к файлу не понятно как писать тесты, и не понятно как выбрать нужные правила для использования в других проектах)

Командная строка

Gogrep (на котором основан Ruleguard) вдохновил меня на то, что бы добавить возможность обрабатывать данные из командной строки в Putout, таким образом:

putout --transform 'module.exports = __a -> const cheers = __a' index.js

Ищем конструкцию module.exports = __a, где __a — любая валидная конструкция JavaScript. Для автоматического исправления достаточно передать флаг fix, и тогда код:

module.exports = {     hello: 'world', };

Превратится в:

const cheers = {     hello: 'world', };

Послесловие

В целом я считаю, что это правильное направление: работа с AST самым простым из возможных путей, и популяризация идеи в массы :). На Go никогда не писал, но смотрю, что для работы с AST, есть все необходимое при чем, как я понимаю, из коробки.

Хочу поблагодарить читателя, очутившегося на этих строках, quasilyte, за создание такого замечательного инструмента, как Ruleguard, надеюсь на дальнейшее развитие и популяризацию автоматизации рефакторинга. А еще на то, что эта статья добавит пищу для размышлений, и возможно, вдохновит на развитие новых идей, инструментов и функциональных возможностей в области статического анализа.

Буду рад любым комментариям с предложениями по обработке синтаксиса на JavaScript (и Go, если quasilyte подключится к беседе).

И, на последок, опрос.