Comments 8
Хотя, если написать их достаточно много, компилятор можно и «свалить». Возможно, это изменят в финальной версии C# 8.0.
А много это сколько? Если в этом случае можно свалить, то и в случае очень большой конкатенации строк можно свалить, т.к. стек не резиновый.
Точно не скажу, если где-то экран текста заполнить восклицательными знаками, оно падало. А размер стека у потоков, которые проверяют код, нам в анализаторе уже приходилось увеличивать (относительно значения по-умолчанию), иначе на некоторых тестовых проектах Roslyn падал, при проверке сгенерированных файлов.
Вот вы говорите специально размечать код не надо. А что делать с ложно-положительными срабатываниями коих обычно под 90%?
В этом и основная проблема анализаторов — шум в разы больше чем сигнал.
В этом и основная проблема анализаторов — шум в разы больше чем сигнал.
Да, безусловно, ложно-положительные срабатывания неизбежны при работе статического анализатора, однако такой огромный процент скорее свидетельствует о том, что анализатор нужно дополнительно настроить перед использованием — отключить какие-то диагностики, добавить исключения на определённые файлы, unit тесты и т.п.
Beta-версия? Ну, может, через годик-другой release будет. А лет через 5 в какой-то beta-версии решат проблему изменяемости структур. Если, конечно, вообще в таком виде C# останется кому-т ещ интересен. Кстати, это в Core убдет тоже, или только под мало кому нужный немежплатформенный Framework. C# от Swift, видать, отстал уже безнадёжно, уже и от Java остаёт.
Продолжение. Nullable Reference не защищают, и вот доказательства.
Sign up to leave a comment.
Nullable Reference типы в C# 8.0 и статический анализ