Спасибо за публикацию. Просто отмечу, что короткий и красивый код, это не обязательно всегда замедление. Конечно, надо понимать, что ты делаешь и зачем. Без этого никак. И тогда вполне возможен сценарий, когда от упрощения и лакончиности все только выигрывают. Вот прямо сейчас разбираю такой случай в здесь – https://t.me/programming_tales/662
Нет методики, даю файл, говорю найди ошибки, изучаю вывод. В целом всё нормально работает и есть полезные наблюдения. Но иногда, переклинивает так, что у меня случается сворачивание глаз в трубочку. Один из таких случаев я и описал.
С точки зрения статического анализа такие наблюдения надо осмыслить. Классические аналиторы тоже выдаёт ложные срабатывания, но делают это детерминировано. Если исключить/поправить все места где выдавались срабатывания - новых не будет. А здесь какой то бесконечный ревью получается, зависящее от... хз от чего :)
Да, это отдельное направление развития статического анализа – фильтрация/разметка предупреждений. Мы планируем начать заниматься этим направлением после большого релиза в этом году, где добавим проверку новых языков программирования (JS, TS, GO).
Решил погуглить, что последний год пишут на тему "поиск ошибок в коде". Раньше находились статьи про разные инструменты, сейчас всё забито статьями с общим названием "Нейросети для поиска ошибок в коде". Заглянул внутрь, например, этой: "Исправить код с помощью нейросети: ИИ для исправления ошибок в коде на Python, JavaScript и в больших проектах".
Спасибо за статью. Не согласен, со словом «нет» в ячейке таблицы: статический анализ – анализирует сквозное влияние изменений.
На самом деле, анализаторы кода уже 100500 лет умеют видеть контекст всей кодовой базы и замечать, как изменение повлияет на работы функций в других файлах. Для этого используются такие технологии как межпроцедурный и межмодульный анализ потока данных.
Естественно, заставляя инструмент анализировать изменения в конкретном файле (инкрементальный анализ) обрубается/усложняется возможность заметить, как эти изменения влияют на другие части проекта. Но и проблемы как таковой нет. Достаточно время от времени выполнять полную проверку проекта, когда включен межмодульный анализ.
Более того ГОСТ Р 71207—2024 (Статический анализ программного обеспечения) явно предписывает выполнять оба вида анализа (см. п. 5.6.).
Статический анализ добавленных или измененных частей ПО следует выполнять после каждого внесенного изменения.
Статический анализ всего разрабатываемого ПО следует выполнять не реже одного раза в 10 рабочих дней, если за данный период времени исходный код был изменен.
Суть – быстро ловим многие ошибки в момент их внесения в код. Время от времени выполняем полный (к сожалению, часто весьма медленный) анализ и выявляем баги при взаимодействии разных модулей. См. вебинар про процессы статического анализа по ГОСТ Р 71207–2024.
Раз история продолжается, я и здесь продублирую позицию по таким комментариям.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Так что это вполне себе метод векторизации, хотя и да, сильно зависимый от компилятора.
Это не метод, а хрень. Это худший вариант кода, что подтверждается замерами. То, что выглядит как оптимизированным, вовсе не обязано таким являться. Вариант с | это уже другой код.
Так жирно, что тонко :)
А если серьёзно, то ещё как! Как раз с Сергеем уже цикл вебинаров есть на тему GameDev и оптимизации:
Оптимизация игр
Оптимизация игр: работа со строками
Инструменты для разработчиков игр и не только
Спасибо за публикацию. Просто отмечу, что короткий и красивый код, это не обязательно всегда замедление. Конечно, надо понимать, что ты делаешь и зачем. Без этого никак. И тогда вполне возможен сценарий, когда от упрощения и лакончиности все только выигрывают. Вот прямо сейчас разбираю такой случай в здесь – https://t.me/programming_tales/662
Нет методики, даю файл, говорю найди ошибки, изучаю вывод. В целом всё нормально работает и есть полезные наблюдения. Но иногда, переклинивает так, что у меня случается сворачивание глаз в трубочку. Один из таких случаев я и описал.
С точки зрения статического анализа такие наблюдения надо осмыслить. Классические аналиторы тоже выдаёт ложные срабатывания, но делают это детерминировано. Если исключить/поправить все места где выдавались срабатывания - новых не будет. А здесь какой то бесконечный ревью получается, зависящее от... хз от чего :)
Да, это отдельное направление развития статического анализа – фильтрация/разметка предупреждений. Мы планируем начать заниматься этим направлением после большого релиза в этом году, где добавим проверку новых языков программирования (JS, TS, GO).
Да, добро пожаловать :) Путеводитель C++ программиста по неопределённому поведению: часть 2 из 11
Дык не важно, подпишись на канал сбежавшая нейросеть
Даже приблизительно спрогнозировать не могу :)
Да, но нет :)
Я сегодня как раз делился наблюдением в заметке Минутка улыбок сеньоров, возящихся с legacy-проектами. :)
Спасибо за статью. Не согласен, со словом «нет» в ячейке таблицы: статический анализ – анализирует сквозное влияние изменений.
На самом деле, анализаторы кода уже 100500 лет умеют видеть контекст всей кодовой базы и замечать, как изменение повлияет на работы функций в других файлах. Для этого используются такие технологии как межпроцедурный и межмодульный анализ потока данных.
Естественно, заставляя инструмент анализировать изменения в конкретном файле (инкрементальный анализ) обрубается/усложняется возможность заметить, как эти изменения влияют на другие части проекта. Но и проблемы как таковой нет. Достаточно время от времени выполнять полную проверку проекта, когда включен межмодульный анализ.
Более того ГОСТ Р 71207—2024 (Статический анализ программного обеспечения) явно предписывает выполнять оба вида анализа (см. п. 5.6.).
Суть – быстро ловим многие ошибки в момент их внесения в код. Время от времени выполняем полный (к сожалению, часто весьма медленный) анализ и выявляем баги при взаимодействии разных модулей. См. вебинар про процессы статического анализа по ГОСТ Р 71207–2024.
Чуть подробнее и с примером написал здесь.
Ну то есть новых проектов нет? У Linux Kernel всё было отлично и раньше.
Не удержался. А можно где-то посмотреть на хороший С++ вайб-код? Может кто-то подсказать открытые проекты?
Тем, кто хочет ещё глубже занырнуть в UB - Путеводитель C++ программиста по неопределённому поведению :)
В точку. Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом.
Раз история продолжается, я и здесь продублирую позицию по таким комментариям.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Завышенные ожидания, а как на практике – оно как-то так.
Это не метод, а хрень. Это худший вариант кода, что подтверждается замерами. То, что выглядит как оптимизированным, вовсе не обязано таким являться. Вариант с
|это уже другой код.Нормальная позиция. У меня вклад 430 статей на Хабре, у вас 0. Набросать вопросов дело не хитрое...
Ну вот я вчера статью написал "Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом". Где я неправ? :)