Комментарии 32
Я не специалист по шарпу, но что не так с SetErrorInfo? Нормальный out-параметр, нет? Ну, если бы это были плюсы, там бы стояла ссылка &
А сам рантайм не проверяли? Он на C, порядка 300к строк, тот еще кошмар :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Позволю себе предположить и разъяснить вам то, почему, по моему мнению «минусуют» — Ваш коментарий не несет никакой смысловой нагрузки, как по отношению к статье, так и к другим коментариям, более того, сам по себе коментарий не несет в себе никакой полезной информации, которая так или иначе, могла бы быть полезна/интересна читателю.
НЛО прилетело и опубликовало эту надпись здесь
А вашему C# анализатору можно скормить Unity3D проект? Формально он собирается той же студией или Mono.
На данный момент C#-анализатор проверяет только *.csproj проекты.
Тогда проблем быть не должно, unity их создаёт.
А вы их честно проверяете — или просто выдергиваете элементы Compile?
Что вы понимаете под 'честной проверкой'?
Проектные файлы используются в том числе и для получения компиляции, из которой извлекается семантическая информация, необходимая для глубокого анализа.
Я об этом писал в этой статье.
Проектные файлы используются в том числе и для получения компиляции, из которой извлекается семантическая информация, необходимая для глубокого анализа.
Я об этом писал в этой статье.
"Честная проверка" означает, что на вход анализатора попадают все участвующие в компиляции файлы, независимо от того, были ли они статически указаны в файле проекта.
Visual Studio, когда подсвечивает код, собирает файлы честно. По крайней мере, 2012я версия — точно. А вот разработчики R#, к примеру, схалтурили...
У меня в некоторых статических классах есть метод Dispose, назван так по аналогии с методом Dispose интерфейса IDisposable, т.к. тоже выполняет очистку ресурсов. PVS студия рекомендует наследоваться от него (V3074), но статические классы нельзя наследовать от интерфейсов. Можно обучить анализатор не выдавать такой совет для статических классов.
И еще такой момент, есть код:
Выдает на него следующее:
Но ведь здесь все логично, проверка или идет до первого срабатывания слева направо, если коллекция не null, хочу проверить наличие элементов в ней. Если бы здесь стояло логическое И, то ошибка была бы понятна, т.к. были бы взаимоисключающие части условия.
if (periods == null || periods.Count() == 0) { /*...*/ }
Выдает на него следующее:
V3063. A part of conditional expression is always true/false if it is evaluated
Но ведь здесь все логично, проверка или идет до первого срабатывания слева направо, если коллекция не null, хочу проверить наличие элементов в ней. Если бы здесь стояло логическое И, то ошибка была бы понятна, т.к. были бы взаимоисключающие части условия.
А покажите, как до этого инициализируется и используется periods.
Да, понял почему выдается предупреждение, periods при расчете не может быть инициализирован null значением, но с другой стороны результат вычисляется на две функции вглубь в другом месте, так что проверку все таки оставить стоит, подстраховаться на случай смены реализации расчета, и возможности возврата null.
В общем, все правильно он показал.
В общем, все правильно он показал.
А почему вы решили сделать его статическим? Его и в using не обернёшь
А его не нужно оборачивать в using, это часть инфраструктурного функционала, который должен работать в течение всего жизненного цикла приложения. Например, в моем случае, это: логирование, планировщик задач по умолчанию, и реализация сигналов. Конечно каждый из вариантов можно сделать не статическим, но в этом случае снизится удобство использования (субъективно).
Например, идея которую предлагает log4net или NLog, где в каждом классе нужно получать логгер, плюс писать что то вроде logger.Log.Info кажется избыточным, а вот идея писать в любом месте Log.Info() минималистичнее и удобнее.
Например, идея которую предлагает log4net или NLog, где в каждом классе нужно получать логгер, плюс писать что то вроде logger.Log.Info кажется избыточным, а вот идея писать в любом месте Log.Info() минималистичнее и удобнее.
Статический метод с сайд-эффектом — зло в квадрате. Рано или поздно появится необходимость переписать. Уж лучше статическое поле, вроде Log.Current.Info() и Log.Current.Dispose() соответственно.
Вопрос в подходе, с теми же логами мне удобно чтобы логи не летели куда-то в централизованное хранилище логов. А лежали непосредственно в файловой системе рядом с приложением. Т.е. в 100% случаев все приложения пишут лог рядом с собой в ФС. Соответственно нужна только одна реализация, переписывать которую не приходилось и вряд ли придется.
Скажите а Xamarin проверять не планируете?
'Xamarin.Forms' проверяли: статья.
Или Вы о чём-то другом?
Или Вы о чём-то другом?
Игра всё таки была не очень сложная, т.к. определить тип ошибки по виду кода было не очень сложно — первым вариантом было последовательное присвоение, вторым — именно одинаковое условие в двух частях тернарного оператора. Беглым просмотром находится идентичные части.
Найди в реальном коде? Сначала подумалось что гораздо сложнее. Потом вдумался. Если я правильно понимаю что делает код, то он выставляет цвет нажатой кнопки. Заметив "баг" будет довольно очевидно, где его искать. Так что, ИМХО, пример для "найди ошибку сам" можно было сделать и посложнее.
Пока могу предложить Вам, например, поиграть в поиск ошибок здесь :)
А вы сообщали разработчиках о найденых ошибках? Есть позитивный опыт общения с ними?
Мой случай закончился никак: я обнаружил причину, почему циклы с Thread.Sleep(1) на Mac OS/iOS жрут 100% CPU, но мейнтейнер репорт не понял, а в итоге перестал рассматривать.
Мой случай закончился никак: я обнаружил причину, почему циклы с Thread.Sleep(1) на Mac OS/iOS жрут 100% CPU, но мейнтейнер репорт не понял, а в итоге перестал рассматривать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ищем ошибки в Mono: сотни их