Раз история продолжается, я и здесь продублирую позицию по таким комментариям.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Так что это вполне себе метод векторизации, хотя и да, сильно зависимый от компилятора.
Это не метод, а хрень. Это худший вариант кода, что подтверждается замерами. То, что выглядит как оптимизированным, вовсе не обязано таким являться. Вариант с | это уже другой код.
Забыл в статье ещё вот на этот пост сослаться, который мне понравился и который транслирует схожие мысли:
...
Главный риск ИИ-кода — не в том, что он плохой, содержит баги, уязвимости и т.п. В том-то и беда, что он выглядит убедительно хорошим. Агент выдаёт что-то, что компилируется, проходит тесты, рендерит красивый UI. И возникает непреодолимый соблазн пустить это в прод, не заглядывая внутрь.
Нет. Тесты это только часть подхода к качеству. Они не заменят построение архитектуры, контроль заимствованных компонент (SCA), проверку оптимальности выбранных алгоритмов и т.д. Не цепляйтесь за одну лучшую методологию. Тесты хорошо, но недостаточно.
Вы можете сами это легко сделать. Проект состоит из одного файла. Скормите его нейронке и попросите её подробно написать, что не так. Потом расскажите :) Я делал такое, глянул на выхлоп и закрыл. Мне такой фигнёй (сравнением) заниматься не интересно.
У PVS-Studio нет проблемы с макросами :) Он их раскрывает перед анализом с помощью препроцессора. Собственно, если этого не сделать, ни о каком нормальном анализ кода речь идти не может. Поэтому PVS-Studio работает только с компилируемым кодом и ему нельзя просто "скормить папку с исходниками".
Судя по таким заметкам, растёт интерес к теме ГОСТ Р 56939, что впрочем не удивительно. Тем, кто хочет погрузиться ещё глубже, предлагаю 30 РБПО вебинаров :)
Причём рассмотрели не всё, что хотели и планируем новый цикл "Надёжность, качество, безопасность ПО: методология и инструменты". Заодно приглашаю всех желающих поучаствовать в качестве экспертов (докладчиков).
Раз история продолжается, я и здесь продублирую позицию по таким комментариям.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Завышенные ожидания, а как на практике – оно как-то так.
Это не метод, а хрень. Это худший вариант кода, что подтверждается замерами. То, что выглядит как оптимизированным, вовсе не обязано таким являться. Вариант с
|это уже другой код.Нормальная позиция. У меня вклад 430 статей на Хабре, у вас 0. Набросать вопросов дело не хитрое...
Ну вот я вчера статью написал "Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом". Где я неправ? :)
Пожалуйста, проведите такой тест и напишите об этом.
Забыл в статье ещё вот на этот пост сослаться, который мне понравился и который транслирует схожие мысли:
Ну там не просто if-ы, а этапа компиляции (
if constexpr). Я к тому, что это работает не так, как вы возможно подумали :)Нет. Тесты это только часть подхода к качеству. Они не заменят построение архитектуры, контроль заимствованных компонент (SCA), проверку оптимальности выбранных алгоритмов и т.д. Не цепляйтесь за одну лучшую методологию. Тесты хорошо, но недостаточно.
Вы можете сами это легко сделать. Проект состоит из одного файла. Скормите его нейронке и попросите её подробно написать, что не так. Потом расскажите :) Я делал такое, глянул на выхлоп и закрыл. Мне такой фигнёй (сравнением) заниматься не интересно.
Продолжу. Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом.
У PVS-Studio нет проблемы с макросами :) Он их раскрывает перед анализом с помощью препроцессора. Собственно, если этого не сделать, ни о каком нормальном анализ кода речь идти не может. Поэтому PVS-Studio работает только с компилируемым кодом и ему нельзя просто "скормить папку с исходниками".
В сложных случаях можно использовать отслеживание сборки, чтобы собрать всю необходимую информацию для анализа – Проверка проектов независимо от сборочной системы (C и C++).
Подробнее про технологии анализа кода, используемые в PVS-Studio: Статический анализатор кода PVS-Studio в 2026: ГОСТ Р 71207, ГОСТ Р 56939, приказ ФСТЭК №117.
Для этого вполне подходит триал.
Если проект открыт, то всё как и было - Бесплатная лицензия PVS-Studio для Open Source.
И теория и практика: 30 вебинаров про разработку безопасного программного обеспечения (РБПО) по ГОСТ Р 56939—2024.
Судя по таким заметкам, растёт интерес к теме ГОСТ Р 56939, что впрочем не удивительно. Тем, кто хочет погрузиться ещё глубже, предлагаю 30 РБПО вебинаров :)
Причём рассмотрели не всё, что хотели и планируем новый цикл "Надёжность, качество, безопасность ПО: методология и инструменты". Заодно приглашаю всех желающих поучаствовать в качестве экспертов (докладчиков).
Для тех, кто хочет разобраться, как подступиться к РБПО и сертификации по ГОСТ Р 56939-2024, я как раз недавно подготовил подборку материалов "Разработка безопасного программного обеспечения по ГОСТ Р 56939—2024".
А теперь всё сразу и в одном месте – ГОСТ56939.РФ
Перечисленные здесь публикации и вебинары легли в основу информационной подборки о разработке безопасного программного обеспечения по ГОСТ Р 56939‑2024. Рекомендую начать с неё ваше знакомство с РБПО.