Как я осуществляю пустую проверку?

Обратите внимание на Gendarme , его можно запускать после сборки вместе с вашими тестами (возможно, перед ними, если хотите), и в нем есть несколько правил, относящихся к проверкам null . Вы также можете довольно просто написать свой собственный.

Платформа .NET стремилась обеспечить принудительную проверку нулевых ссылок во время компиляции с помощью! модификатор.

public void MyMethod(!string cannotBeNull)

Но, увы, у нас нет проверки времени компиляции. Лучше всего свести к минимуму количество случаев, когда внешние вызывающие объекты будут передавать нулевые значения, а затем принудительно применить нулевые проверки для общедоступных методов:

public class ExternalFacing
{
  public void MyMethod(string arg)
  {
     if (String.IsNullOrEmpty(arg))
        throw new ArgumentNullException(arg);

     implementationDependency.DoSomething(arg);
   }
}

internal class InternalClass
{
    public void DoSomething(string arg)
    {
         // shouldn't have to enforce null here.
    }
}

Затем примените соответствующие модульные тесты к внешнему классу, чтобы ожидать ArgumentNullExceptions.

Ни то, ни другое невозможно в C # 3. Вам придется использовать что-то вроде Spec # ... я думаю, что в C # 4 может быть что-то из этого встроено, но я не уверен в этом.

spec #: http://research.microsoft.com/en-us/projects/specsharp

100% покрытие кода ничего не значит.

Это ложное чувство безопасности.

Единственное, что вы измеряете, - это то, что вы выполняете все строки кода.

Нет:

• Эти строки кода - это все строки кода, которые должны были быть там
• Эти строки кода работают правильно (вы проверяете все крайние случаи?)

Например , если ваша процедура борьбы с пожаром содержит 1 шаг «выбежать из здания», то, даже если это происходит в 100% случаев, возможно, лучшей процедурой было бы «предупредить пожарную охрану, попытаться остановить пожар. , а затем закончится, если все остальное не поможет ".

В C # нет ничего, что могло бы помочь вам в этом, если бы вы специально не входили и не добавляли код, либо контракты кода (.NET 4.0), либо определенные IF-операторы (<4.0).

Вы не можете иметь проверку на null во время компиляции, поскольку во время компиляции объекты являются только типами, и только во время выполнения типы преобразуются в экземпляры, которые имеют конкретное значение ... здесь null.

Защитное программирование может только увести вас ... может быть, лучше поймать исключение и обработать его, как и любое другое.

1) Я думаю, что Resharper может предложить вам проверить некоторые критические места в вашем коде. Например, он предлагает добавить [код проверки нулевых ссылок] и добавляет его, если вы разрешите.

Попробуйте. Это увеличит ваш опыт, если вам это нужно, конечно.

2) Используйте паттерн "Fail Fast" (или assert, assertions) в своем коде на ранней стадии разработки приложения

Это не техническое решение, а социальное. Просто сделайте неприемлемым в вашей среде доступ к ссылочному типу без проверки на null, если ссылочный тип был каким-либо образом изменен внешним кодом (вызов другого метода и т. Д.). Модульное тестирование не заменяет старый добрый обзор кода.

Возможно, я ошибаюсь, но я думаю, что у FxCop есть правило, которое предлагает вам добавлять в код проверки нулевых ссылок. Вы можете попробовать запустить свои сборки с помощью инструмента и посмотреть, что он скажет.

Есть ли способ принудительной проверки null во время компиляции?

Нет. Компилятор не может определить, указывает ли переменная-ссылка во время выполнения на null.

И исключить операторы, производящие null (множества и возвраты), тоже недостаточно. Рассмотрим:

public class Customer
{
  public List<Order> Orders {get;set;}
}
  //now to use it
Customer c = new Customer;
Order o = c.Orders.First(); //oops, null ref exception;

Возможно, вам стоит взглянуть на пользовательские политики проверки анализа кода для TFS

http://weblogs.asp.net/uruit/archive/2009/03/17/writing-custom-rules-for-tfs-2008-code-analysis-check-in-policy.aspx