6 /10

1c-language-parser

https://github.com/LazarenkoA/1c-language-parser
Нормально

Прожарка: 1c-language-parser

Оценка: 6/10

Критично

  • [✓ ФАКТ: CVE-Ищейка] trivy – у проекта две HIGH‑уязвимости в зависимости golang.org/x/text (CVE‑2021‑38561, CVE‑2022‑32149). При сборке под любой Go‑версией они могут привести к отказу службы. Нужно обновить модуль до версии, где патчи включены.
  • [✓ ФАКТ: Инфра-Ревизор] checkov – в CI‑конвейере (.github/workflows/go.yml) нарушено правило CKV2_GHA_1: действие actions/checkout@v3 запускается без указания fetch-depth: 0, что оставляет историю неполной и усложняет аудит.
  • [✓ ФАКТ: YAML-Граммарнаци] yamllint – файл workflow содержит 6 синтаксических ошибок (слишком длинная строка, отсутствие ---, неправильные отступы, лишние пробелы в скобках). GitHub‑Actions может отказываться от выполнения или работать с непредсказуемыми параметрами.

Надо переделать

  • [⚠ МНЕНИЕ] Отсутствие тестов – в репозитории есть только *_test.go в пакете ast, но они покрывают лишь токены и парсер‑грамматику, без интеграционных проверок. Добавьте набор юнит‑тестов, проверяющих построение AST для типовых конструкций 1С.
  • [⚠ МНЕНИЕ] Неиспользуемый код – файл ast/fast_tolower/gowrap.go объявляет функции ToLowerFast, но нигде в проекте они не вызываются. Удалите или подключите их в процесс токенизации.
  • [⚠ МНЕНИЕ] Именование и комментарии – многие функции (NewAST, Parse, Print) имеют хорошие названия, но внутри файлов почти нет комментариев, поясняющих правила грамматики или структуру узлов. Добавьте doc‑строки, особенно в grammar.y и ast_struct.go.
  • [⚠ МНЕНИЕ] Форматирование Go‑кода – в нескольких файлах (например, examples/pretty_code/main.go) присутствуют длинные строки‑литералы, которые делают чтение кода тяжёлым. Разбейте их на несколько строк или вынесите в отдельные константы.
  • [✓ ФАКТ: YAML-Граммарнаци] CI‑workflow – исправьте все ошибки yamllint, добавьте шаг go vet и staticcheck, а также ограничьте кэширование зависимостей для ускорения сборки.

Мелочи

  • [⚠ МНЕНИЕ] В go.yml использовано truthy‑значение on: [push, pull_request] без кавычек – поправьте на true/false.
  • [⚠ МНЕНИЕ] В README.md отсутствует блок «License», хотя файл LICENSE присутствует – добавьте ссылку.
  • [⚠ МНЕНИЕ] В examples/pretty_code/main.go импортируется пакет fmt, но вывод ошибки происходит через fmt.Println без форматирования – лучше использовать log.Fatalf.
  • [⚠ МНЕНИЕ] Файл ast/y.go содержит только один тип‑объявление, которое могло бы быть размещено в ast_struct.go.

Что хорошо

  • [⚠ МНЕНИЕ] Явная архитектура – весь парсер сосредоточен в пакете ast, где находятся грамматика (grammar.y), структуры AST и вспомогательные функции. Это упрощает навигацию.
  • [⚠ МНЕНИЕ] Yacc‑грамматика – использование go yacc даёт быстрый и детерминированный парсер, а файл grammar.y достаточно читаем, хотя и без комментариев.
  • [⚠ МНЕНИЕ] Пример использования – директория examples/pretty_code демонстрирует, как построить AST из строки 1С‑кода и вывести его в читаемом виде. Это полезно для новых участников.
  • [⚠ МНЕНИЕ] Лицензия и README – в репозитории присутствуют файл LICENSE с указанием автора и подробный README, описывающий назначение проекта и способ установки.
  • [⚠ МНЕНИЕ] Минимальные зависимости – кроме golang.org/x/text и github.com/alecthomas/participle (неявно), проект не тянет тяжёлых внешних библиотек, что облегчает сборку.

Вердикт

Добротный парсер с чёткой структурой, но без тестов, с уязвимыми зависимостями и «кривыми» CI‑скриптами – требует доработки, чтобы стать надёжным инструментом.

Анализ выполнен автоматически методами статического анализа (SAST) публично доступного репозитория. Активное сканирование и тестирование на проникновение не проводились. Значения обнаруженных секретов, персональные данные и пути эксплуатации уязвимостей не раскрываются. Цитирование кода — в соответствии со ст. 1274 ГК РФ. Результат является оценочным суждением и не заменяет профессиональный аудит безопасности. Пункты помечены: ✓ факт (линтер), ⚠ мнение (AI), ✗ неверно (опровергнуто).

Raw Markdown Прожарить ещё