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

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

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

Вот и давай обсудим. Для выяснения.

Раз тесты отдельно, ИИ — отдельно, значит на мой вопрос о том, запускает ли он тесты под собой в стиле профайлера, ответ — нет, не запускает.

Впрочем, ты это фактически сам признал, дезавуировав (удалив) свое заявление. Но RSDN все помнит.

S>При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.https://pvs-studio.com/en/blog/posts/cpp/0543/

Принял к сведению. Вопрос ясен — он информацию, которая могла бы быть получена от прохождения тестов, не получает и поэтому не использует.

Тогда остается только статический (без выполнения) анализ.

Я готов допустить в принципе, что он тут лучше других статических анализаторов. Есть некоторые сомнения, просто из тех соображений, что авторы той же PVS Studio ее десяток, если не больше, лет пилят и всех собак в округе съели, а тут явился кто-то и одним махом их всех превзошел. Но допустим все же.

Но любой статический анализ никогда не может дать ту информацию, которую дает анализ в рантайме. То есть анализ, проведенный профайлером или Code Coverage.

Например Code Coverage мне покажет каждую строчку, которая не выполнялась при прохождении тестов. Он не будет говорить, что тут что-то неверно, да, но он четко скажет, что вот этот if или else или метод никогда не выполнялся, а значит, верно тут или нет — при данном наборе тестов вообще неизвестно. Я своих студентов в это тыкал постояннно.

Ну а что тут еще может добавить профайлер — думаю, сам знаешь, лень описывать. Например, может ли твой ИИ сказать, сколько раз выполнялся этот метод ? Кто тут главный потребитель времени ? Кто тут больше всего создает мусора в хипе ? Я уж молчу про взаимодействие потоков и дедлоки.

Это твой ИИ сможет ? Без запуска, только, как ты писал, "смотрит на код" ?

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

S>Речь о том, что ИИ находит косяки, которые никакие другие инструменты найти не могут.

А вот тут я двумя руками за. Пусть находит. Еще один инструмент в ряду других. Со своими преимуществами и ограничениями. Все нормально.

В общем, вспоминаю Ф. Искандера

Недели через две, когда замолкли последние залпы контрпропаганды и нашествие козлотуров было полностью подавлено, а их рассеянные, одиночные экземпляры, смирившись, вошли в колхозные стада,...

Вот так и ИИ войдет в этой области.

S>Так вот ИИ отличается от всех этих прекрасных инструментов как раз тем, что он не требует рукопашного написания сотен правил заранее. Ему достаточно скормить код проекта, и он сам найдёт, какие функции нужно проверять, а какие нет.

Вполне принимаю. Пусть ищет. Еще один инструмент.

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

А IDEA это дедушка, все же ? Просто она это делает, а PVS такой функциональности нет, не предусмотрено.

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

Тогда тем более я должен бояться изменений, которые сделает ИИ. IDEA все же делает их локально, в пределах нескольких строк. Если не понравится это точечное изменение — откачу, и все. А тут какой-то глобальный анализ, затрагивающий много строк разных файлов, и я совсем не уверен, что там все будет сделано правильно. А в итоге — мой код уже не мой код, и я ему как своему доверять не могу. И не коллега его правил. С коллегой можно побеседовать, он объяснит, почему он такие изменения сделал, обсудим, может, он признает, что где-то неправ, может, я признаю. А тут мне что, дискуссию с ИИ начинать ? И даже если удастся ее провести, а ну как его аргументы меня не убедят ? Я такого намного больше боюсь.

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

Я с этим согласен. Пусть делает, ничего плохого. Только все же лучше пусть код не правит, а представит мне на рассмотрение со своим аргументами. Ну и хотелось бы иметь возможность с ним подискутировать, если сочту нужным. И возможность что-то принять,а что-то отвергнуть, а он пусть скажет, можно ли сделать такое частичное изменение и не приведет ли это к плохим последствиям. Черт его знает, что он там в итоге накрутил, как там одно связано с другим. Интеллект все же

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

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

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

Вот и давай обсудим. Для выяснения.

Раз тесты отдельно, ИИ — отдельно, значит на мой вопрос о том, запускает ли он тесты под собой в стиле профайлера, ответ — нет, не запускает.

Впрочем, ты это фактически сам признал, дезавуировав (удалив) свое заявление. Но RSDN все помнит.

S>При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.https://pvs-studio.com/en/blog/posts/cpp/0543/

Принял к сведению. Вопрос ясен — он информацию, которая могла бы быть получена от прохождения тестов, не получает и поэтому не использует.

Тогда остается только статический (без выполнения) анализ.

Я готов допустить в принципе, что он тут лучше других статических анализаторов. Есть некоторые сомнения, просто из тех соображений, что авторы той же PVS Studio ее десяток, если не больше, лет пилят и всех собак в округе съели, а тут явился кто-то и одним махом их всех превзошел. Но допустим все же.

Но любой статический анализ никогда не может дать ту информацию, которую дает анализ в рантайме. То есть анализ, проведенный профайлером или Code Coverage.

Например Code Coverage мне покажет каждую строчку, которая не выполнялась при прохождении тестов. Он не будет говорить, что тут что-то неверно, да, но он четко скажет, что вот этот if или else или метод никогда не выполнялся, а значит, верно тут или нет — при данном наборе тестов вообще неизвестно. Я своих студентов в это тыкал постояннно.

Ну а что тут еще может добавить профайлер — думаю, сам знаешь, лень описывать. Например, может ли твой ИИ сказать, сколько раз выполнялся этот метод ? Кто тут главный потребитель времени ? Кто тут больше всего создает мусора в хипе ? Я уж молчу про взаимодействие потоков и дедлоки.

Это твой ИИ сможет ? Без запуска, только, как ты писал, "смотрит на код" ?

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

S>Речь о том, что ИИ находит косяки, которые никакие другие инструменты найти не могут.

А вот тут я двумя руками за. Пусть находит. Еще один инструмент в ряду других. Со своими преимуществами и ограничениями. Все нормально.

В общем, вспоминаю Ф. Искандера

Недели через две, когда замолкли последние залпы контрпропаганды и нашествие козлотуров было полностью подавлено, а их рассеянные, одиночные экземпляры, смирившись, вошли в колхозные стада,...

Вот так и ИИ войдет в этой области.

S>Так вот ИИ отличается от всех этих прекрасных инструментов как раз тем, что он не требует рукопашного написания сотен правил заранее. Ему достаточно скормить код проекта, и он сам найдёт, какие функции нужно проверять, а какие нет.

Вполне принимаю. Пусть ищет. Еще один инструмент.

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

А IDEA это дедушка, все же ? Просто она это делает, а PVS такой функциональности нет, не предусмотрено.

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

Тогда тем более я должен бояться изменений, которые сделает ИИ. IDEA все же делает их локально, в пределах нескольких строк. Если не понравится это точечное изменение — откачу, и все. А тут какой-то глобальный анализ, затрагивающий много строк разных файлов, и я совсем не уверен, что там все будет сделано правильно. А в итоге — мой код уже не мой код, и я ему как своему доверять не могу. И не коллега его правил. С коллегой можно побеседовать, он объяснит, почему он такие изменения сделал, обсудим, может, он признает, что где-то неправ, может, я признаю. А тут мне что, дискуссию с ИИ начинать ? И даже если удастся ее провести, а ну как его аргументы меня не убедят ? Я такого намного больше боюсь.

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

Я с этим согласен. Пусть делает, ничего плохого. Только все же лучше пусть код не правит, а представит мне на рассмотрение со своим аргументами. Ну и хотелось бы иметь возможность с ним подискутировать, если сочту нужным. И возможность что-то принять,а что-то отвергнуть, а он пусть скажет, можно ли сделать такое частичное изменение и не приведет ли это к плохим последствиям. Черт его знает, что он там в итоге накрутил, как там одно связано с другим. Интеллект все же

А то ведь может крайне неприятная ситуация возникнуть. Вот есть у меня код, который я писал и тестировал несколько лет назад. Я ему вполне доверяю и о нем не думаю. А в нем ошибка все же есть, только она никогда не проявлялась, так уж вышло. Я этот код в новый проект вставил, без анализа. Он ошибку в нем нашел. Спасибо ему. И поправил. И неверно поправил, потому что он что-то в моем коде не понял. И результатом этого исправления будет вот что. Код будет работать иначе для этого редкого случая, может и лучше. Вот только в половине остальных обычных случаях он работать перестанет. И что мне теперь делать, если, начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей ? Сидеть и вспоминать, что я там такое 3 года назад написал, и как это с его исправлениями вяжется и как мне сделать, чтобы его "улучшения" мне все не ломали ?