Comments 13
А интересно, есть языки программирования, для которых не нужны подобные анализаторы? Т.е. ЯП, которые изначально так спроектированы, что они в принципе не позволяют совершить многие ошибки. Видимо, для этого нужно запретить «ручное» выделение памяти, преобразование типов и т.п. Вместо if/for/… должны быть другие конструкции. И в итоге мы получаем какой-нибудь Haskell с высоким порогом вхождения и вопросами в плане производительности. Вот, сам и ответил на свой вопрос :(
Ada выглядит вполне неплохо в этом плане. Не модно конечно. И не стильно/молодежно, но там в принципе часть вопросов статического анализа как раз закрыта на уровне языка.
Rust много чего проверяет на этапе компиляции и требует явного приведения типов. Он позволяет предотвратить многие ошибки связанные с управлением памятью.
Go.
Я бы еще отметил Kotlin от JetBrains
UFO just landed and posted this here
В статье ссылка 'V3021' ведёт на 'V302'
У меня в проекте V3062 срабатывает на код вида var vm = container.Get(); vm.Navigate(vm);
При этом, вызываемый метод выглядит как-то так: public void Navigate(T viewModel) { var t = typeof(T);… }
Т.е. параметр viewModel используется в том числе и для получения информации о типе переданного аргумента.
Нельзя ли сделать, чтобы эта диагностика не срабатывала, при условии, что метод не является static, и подозрительный параметр имеет тип из generic определения метода? А описанный сценарий — вынести в другую диагностику, чтобы можно было ее отдельно выключать.
При этом, вызываемый метод выглядит как-то так: public void Navigate(T viewModel) { var t = typeof(T);… }
Т.е. параметр viewModel используется в том числе и для получения информации о типе переданного аргумента.
Нельзя ли сделать, чтобы эта диагностика не срабатывала, при условии, что метод не является static, и подозрительный параметр имеет тип из generic определения метода? А описанный сценарий — вынести в другую диагностику, чтобы можно было ее отдельно выключать.
Мне кажется, что не стоит каждый «всегда лживый/истинный» код считать ошибкой. Иногда это просто защита от дурака. Например, выполнили проверку X0 && Y>0), просто на случай, что кто-нибудь в будущем может, скажем, убрать знак '=' в первой проверку, просто потому что между двумя проверками появится новый код, который будет требовать этого. И вот, из за невнимательности он создал баг, которого можно было избежать за долго до его появления.
К тому же, иногда полная проверка (X>0 && Y>0) имеет какой-то смысл, например в математической формуле и сразу будет бросаться в глаза знающему человеку, который поймет что именно здесь высчитывается та самая часть формулы.
К тому же, иногда полная проверка (X>0 && Y>0) имеет какой-то смысл, например в математической формуле и сразу будет бросаться в глаза знающему человеку, который поймет что именно здесь высчитывается та самая часть формулы.
Sign up to leave a comment.
Accord.Net: ищем ошибку в коде, из-за которой машины поработят человечество