Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А все-так, пожалуйста, объясните, как работает.
Охрененно работает, между нами говоря.

PD>Я что-то вижу противоречие между "ИИ посмотрел — и увидел, что логика нарушена" и словами из прошлого сообщения о том, что он делает свой анализ после запуска unit тестов.
Нет никакого противоречия. Тесты — отдельно, ИИ — отдельно. Речь о том, что ИИ находит косяки, которые никакие другие инструменты найти не могут.

PD>На что именно посмотрел ? На код или еще и на результат прохождения юнит-тестов ?
На код.

PD>Вообще-то юнит — тесты сами либо ничего не сообщают, либо выдают информацию про непрошедшие assert или про падению по исключению. Поэтому просто при их запуске ничего о том, что происходило внутри, узнать не удастся.
Дофига всего удастся. ИИ умеет, к примеру, по выхлопу юнит-тестов и исходному коду разобраться в первопричине проблемы, порыться в спецификациях проекта и решить — толи это тест косячный (тестирует неактуальные инварианты), или в коде реально баг. А потом починить проблему.
Раньше это могло быть типичной практикой для джуна — "смотри, вот у нас после этого коммита CI репортит фейлы юнит-тестов. Иди разберись и почини".

Но это другой вопрос, который в исходном топике не ставился. Если интересно — можем и его обсудить.


PD>Ну слава богу. Если бы анализатор выдал просто "CreateFile result not checked",
Не "CreateFile result not checked", a "function return value is ignored". Разница — в том, что первый тип сообщения опирается на то, что кто-то когда-то построил ОГРООООООООМный список функций стандартной библиотеки, и для каждой из них написал, можно ли игнорировать её результат. И если я в проекте написал свою собственную функцию, то инструмент понятия не имеет, можно ли игнорировать её результат или нет.
Так вот ИИ отличается от всех этих прекрасных инструментов как раз тем, что он не требует рукопашного написания сотен правил заранее. Ему достаточно скормить код проекта, и он сам найдёт, какие функции нужно проверять, а какие нет.

PD>if(hFile == INVALID_HANDLE_VALUE) ...
PD>вполне мог бы.
А если бы у бабушки...

PD>Да бог с ней, с PVS. Мне IDEA для программ на Java то и дело выдает всякие рекомендации типа "этой переменной стоит дать модификатор final" или "лучше заменить вызов лямбда-функции на ссылку на метод" и т.п. Но сама не делает обычно, а предлагает мне подтвердить. Соглашусь — сделает. А еще у нее есть пункт "Code cleanup", и там она автоматом все изменения делает. Я его боюсь
А, ну так это подход пред-предыдущего поколения. Проактивные рефакторинги, да. Ну, кстати, бояться — правильно: далеко не все средства рефакторинга хорошо написаны. В идеале, они не должны ломать семантику кода (за исключением, быть может, экзотических сценариев — вроде наличия доступа через рефлекшн замаскированным способом. Если у нас там есть в код, который в рантайме вычисляет имя метода как "foobar", и потом по нему обращается, то никакой инструмент не сможет это отловить при рефакторинг-переименовании из foobar в barfoo). Но на практике я, емнип, для TS встречал какие-то инструменты, которые мне неверно трансформировали код.

Но опять: этот подход основан на заранее закодированных паттернах. Есть чёткий список правил "что мы считаем кодом, для которого возможны улучшения". Например — не-final поле, в которое нет присваиваний за пределами конструктора. Есть чёткий список правил "как улучшить код, на котором сработало правило номер X". Эти правила придуманы и закодированы заранее.
Очень иногда тулчейн можно кастомизировать за пределами включения/выключения каких-то правил. Например, научить его обнаруживать нарушения локальных правил вроде "в моём проекте все однобуквенные переменные должны быть целыми". Но опять — это ручная работа, которая требует предварительной подготовки.