Мы разрабатываем статический инструмент анализа кода, который направлен на улучшение кода с помощью некоторых подсказок.Как найти потенциальные точки исключения NullReferenceException в утилите анализатора статического кода?
Мы хотим найти места, где разработчик забыл проверить недействительность переменной или свойства или метода return и получил доступ к элементам через Dot Notation, поскольку он может столкнуться с NullReferenceException.
Например, этот код:
class Program
{
static void Main(string[] args)
{
var human = new Human();
if (human.Name.Length > 10)
{
// Jeez! you have a long name;
}
}
}
public class Human
{
public string Name { get; set; }
}
Мы используем Mono.Cecil и мы находим тело всех методов всех типов в данной сборке, и для каждого тела метода мы находим Инструкцию о нем, и то мы проверяем операции Callvirt. Тем не менее, что не поддерживает этот пример:
class Program
{
static string name;
static void Main(string[] args)
{
if (name.Length > 10)
{
}
}
}
Как мы можем найти все доступы к членам (переменный, поле, свойство, метод) данный обнуляемого типа?
Update: На самом деле мы ищем Opcodes, которые представляют доступ члена для данной переменной в IL. Это возможно?
Вы хотите создать инструмент, который выполняет статический анализ кода с использованием отражения, * который не является небольшим подвигом *, но имеет основной вопрос о том, как использовать отражение? Я думаю, вы ставите телегу перед лошадью на этом. Я рекомендую вам сначала узнать все о рефлексии. Затем вам нужно будет узнать, как разрушить метод, чтобы ваш код мог находить случаи, подобные приведенным выше (это более сложная часть). О да, и после этого вам придется как-то уведомить пользователя (не уверен, что это встроенный или через консольный вывод). Кстати, есть инструменты, которые уже много делают. – Igor
Инструмент, такой как https://www.jetbrains.com/resharper, даст вам знать (inline), если есть возможность исключения NullReferenceException, среди прочего. –
@Igor Мы уже разработали анализ/качество кода на основе * TFS * с использованием * Политики регистрации *. В настоящее время он проверяет более 180 правил, которые мы определили, чтобы улучшить качество множества огромных кодовых баз, которые разрабатываются примерно 15 разработчиками. Этот вопрос касается нового правила, которое мы хотим добавить: проверка Null должна быть там, где требуется, для предотвращения исключения NullReferenceException. –