Comments 10
Можно кроме рассуждений о вероятностях, привести реальный пример? Было бы интересно, тем более, что вам будет проще найти материал для статьи.
Я имею ввиду, как соавтору PVS-Studio. А то действительно, статья на «Я пиарюсь» выходит.
А какой я тут могу привести пример? Берем лабораторную работу и не находим там ошибок, а потом берём Clang и находим в нём? Точно также можно сказать, что это не пример, а лабуда какая-то и будем правы.
Необходимы статистические исследования. А это, извините, очень дорого и заниматься подобным просто так ни буду, ни я, ни кто-то другой. Так что придётся опираться на данные собранные другими.
Необходимы статистические исследования. А это, извините, очень дорого и заниматься подобным просто так ни буду, ни я, ни кто-то другой. Так что придётся опираться на данные собранные другими.
Собственно, про линейную экстраполяцию лучше и не скажешь: xkcd.com/605/
Приведены данные аж 1998 (!!!) года. Неужто за почти 15 лет не нашлось более свежего исследования?
Во все нормальные IDE сейчас встраивают статический анализ кода, так что вопрос анализировать или не анализировать статически уже вобщем-то не стоит.
Во все нормальные IDE сейчас встраивают статический анализ кода, так что вопрос анализировать или не анализировать статически уже вобщем-то не стоит.
Вы знаете, так получилось, что мы работаем (в результате, хотя никто этого не ожидал) над очень большим проектом. Безумно большим проектом.
И ошибки делятся на три класса: «опечатка», «ошибка в проектировании» и «ой, а мы и не знали, что компонента ХХХ может YYY когда ZZZ».
Ловить первые — одно удовольствие. Вторые — ад и мучение, потому что перед тем как сказать «да тут всё нафиг переписывать надо» нужно ещё сказать что не так, а это бывает безумно сложно — например, трёхуровневый race condition между приложениями на нескольких системах, написанных на разных языках программирования.
И ошибки делятся на три класса: «опечатка», «ошибка в проектировании» и «ой, а мы и не знали, что компонента ХХХ может YYY когда ZZZ».
Ловить первые — одно удовольствие. Вторые — ад и мучение, потому что перед тем как сказать «да тут всё нафиг переписывать надо» нужно ещё сказать что не так, а это бывает безумно сложно — например, трёхуровневый race condition между приложениями на нескольких системах, написанных на разных языках программирования.
Тоже хотел написать, что статические анализаторы ловят только опечатки, поэтому Макконнелл тут притянут за уши — нелинейный рост количества ошибок в больших проектах связан с совершенно другими классами ошибок, которые анализаторам не по зубам.
Всё тоже самое. Понятно, что ошибки бывают разные. И я писал, что анализатор находит только часть из них. Однако плотность ошибок, которые может найти анализатор, точно также растет в большой программе.
Например, очень сложно в курсовой работе неправильно инстанцировать класс std::vector. А других шаблонов там может и не быть. В большой же программе, можно запросто неверно инстанцировать один из классов. Вот как раз сегодня описал подобный случай в блоге. И не важно, как такое произошло. Рефакторинг, неаккуратность,… Не знаю. Но как говорится, большой программе, большие глюки!
Например, очень сложно в курсовой работе неправильно инстанцировать класс std::vector. А других шаблонов там может и не быть. В большой же программе, можно запросто неверно инстанцировать один из классов. Вот как раз сегодня описал подобный случай в блоге. И не важно, как такое произошло. Рефакторинг, неаккуратность,… Не знаю. Но как говорится, большой программе, большие глюки!
А ничего, что по х вы нелинейно отсчитываете?
Sign up to leave a comment.
Ощущения, которые подтвердились числами