Статический анализ: baseline файлы vs diff

Как по мне, анализировать просто текстовый дифф всё же не очень надёжно, поскольку тот же class MemeDirector { можно разбить на три строчки (каждый токен на своей строке), и по диффу будет уже ничего не понять. Можно сравнивать разницу между уже распаршенным состоянием индекса до и после изменений и высчитывать разницу таким образом (какие классы/функции/константы добавились или удалились).

Ещё один минус подхода с диффом — если в компании используется другая система контроля версий, нежели поддерживает утилита, то анализатор использовать не получится. Хотя, конечно, использующих что-то отличное от git надо ещё поискать :).

Ещё более сомнительный подход есть: если разрешено модифицировать исходные коды в репозитории (вернее, это один раз всего нужно сделать), то можно в конце каждой строки с предупреждениями добавить комментарий, например вида // noverify undefined #1234, и этот ID будет храниться где-то в базе данных и будет содержать все предупреждения для этой строки и её содержимое (без учёта форматирования). Новые ID автоматически добавлять должно быть запрещено. Таким образом вся кодовая база будет один раз "размечена" и существующий legacy-код можно переносить куда угодно, даже постепенно рефакторить, и baseline будет "переезжать" вместе со строчками с предупреждениями. Также, чтобы эти маркеры нельзя было просто скопировать в новый код и таким образом избавится от предупреждений линтера, нужно проверять, что каждый ID существует в кодовой базе не более одного раза и что текст каждой строчки (без учёта пробелов) совпадает с тем, что было изначально записано в базу данных для baseline.

Из минусов:

1. git blame будет показывать другого автора на этих строках, но можно и даже это обойти, если сделать несколько коммитов с git commit --author=<username> с изменениями от соответствующих авторов (можно заодно посчитать, чей код больше всего предупреждений вызывал :))
2. Есть риск сломать парсинг файла (особенно phpdoc). Для этого нужно распарсить файл до и после добавления комментариев и сравнить их AST, чтобы убедиться, что ничего добавление комментария не сломало.

Основной сложностью будет правильно классифицировать строки изменений и выявить все их зависимости, не замедлив алгоритм до уровня full diff с двойным обходом кодовой базы.

На самом интересном закончилось. Подробностей бы.