Я создаю библиотеки классов, некоторые из которых используются другими во всем мире, и теперь, когда я начинаю использовать Visual Studio 2010, я задаюсь вопросом, насколько хорошая идея для меня перейти на использование контрактов кода вместо обычные операторы if в старом стиле.
т. вместо этого:
if (fileName == null)
throw new ArgumentNullException("fileName");
используйте это:
Contract.Requires(fileName != null);
Причина, по которой я спрашиваю, состоит в том, что я знаю, что статическая проверка мне недоступна, поэтому я немного нервничаю из-за некоторых предположений, которые компилятор не может проверить. Это может привести к тому, что библиотека классов не будет компилироваться для тех, кто ее загружает, когда у них есть статическая проверка. Это, в сочетании с тем фактом, что я не могу даже воспроизвести проблему, сделало бы ее утомительным решение, и я бы понял, что это не говорит о качестве моей библиотеке классов, если она, по-видимому, даже не компилируется из коробка.
Итак, у меня есть несколько вопросов:
- Статическая проверка включена по умолчанию, если у вас есть доступ к ней? Или есть настройка, которую мне нужно включить в библиотеке классов (а так как у меня нет статической проверки, у меня не будет)
- Мои страхи необоснованны? Является ли приведенный выше сценарий реальной проблемой?
Любой совет будет приветствоваться.
Редактировать : Позвольте мне уточнить, что я имею в виду.
Допустим, у меня есть следующий метод в классе:
public void LogToFile(string fileName, string message)
{
Contracts.Requires(fileName != null);
// log to the file here
}
и тогда у меня есть этот код:
public void Log(string message)
{
var targetProvider = IoC.Resolve<IFileLogTargetProvider>();
var fileName = targetProvider.GetTargetFileName();
LogToFile(fileName, message);
}
Теперь, здесь, IoC включается, разрешает некоторый «случайный» класс, который предоставляет мне имя файла. Допустим, что для этой библиотеки нет никакого способа, которым я мог бы вернуть класс, который не дал бы мне непустое имя файла, однако, из-за природы вызова IoC, статический анализ не может проверить это и, следовательно, может предполагать, что возможное значение может быть нулевым.
Следовательно, статический анализ может заключить, что существует риск вызова метода LogToFile с аргументом null и, следовательно, невозможности его построения.
Я понимаю, что могу добавить в код предположения, говоря, что компилятор должен принять его так, как если бы fileName, который я получаю от этого метода, никогда не будет нулевым, но если у меня нет статического анализатора ( VS2010 Professional), приведенный выше код будет скомпилирован для меня, и, таким образом, я могу оставить это как спящую ошибку для кого-то с Ultimate, чтобы найти. Другими словами, не было бы предупреждения во время компиляции, что здесь может быть проблема, поэтому я мог бы выпустить библиотеку как есть.
Так это реальный сценарий и проблема?