Почему FxCop считает, что инициализировать поля значениями по умолчанию - это плохо?

В некоторых случаях это может дать значительный выигрыш в производительности. Подробнее см. здесь. Статья CodeProject.

Основная проблема в том, что в C # это не нужно. В C ++ все по-другому, поэтому многие профессора учат, что вы всегда должны инициализировать. В .NET изменился способ инициализации объектов.

В .NET объекты всегда инициализируются при создании. Если вы добавите инициализатор, возможно (обычно) вы вызовете двойную инициализацию ваших переменных. Это происходит независимо от того, инициализируете ли вы их в конструкторе или встроенном.

Кроме того, поскольку в .NET инициализация не требуется (это всегда происходит, даже если вы явно не указываете инициализировать значение по умолчанию), добавление инициализатора предполагает, с точки зрения удобочитаемости, что вы пытаетесь добавить код, имеющий функция. Каждый фрагмент кода должен иметь цель или быть удален, если в нем нет необходимости. «Дополнительный» код, даже если он был безвредным, предполагает, что он существует по какой-то причине, что снижает ремонтопригодность.

Рид Копси сказал, что указание значений по умолчанию для полей влияет на производительность, и он ссылается на тест 2005 года.

public class A
{
    // Use CLR's default value
    private int varA;
    private string varB;
    private DataSet varC;
}

public class B
{
    // Specify default value explicitly
    private int varA = 0;
    private string varB = null;
    private DataSet varC = null;
}

Спустя восемь лет и четыре версии C # и .NET я решил повторить этот тест для .NET Framework 4.5 и C # 5, скомпилированного как Release с оптимизацией по умолчанию с использованием Visual Studio 2012. Я был удивлен, увидев, что разница в производительности все еще сохраняется. между явной инициализацией полей их значениями по умолчанию и не указанием значения по умолчанию. Я ожидал, что более поздние компиляторы C # к настоящему времени уже не будут оптимизировать эти константы.

No init: 512,75    Init on Def: 536,96    Init in Const: 720,50
Method No init: 140,11    Method Init on Def: 166,86

^{(остальное)}

Итак, я заглянул внутрь конструкторов классов A и B в этом тесте, и оказалось, что оба пусты:

.method public hidebysig specialname rtspecialname 
    instance void .ctor () cil managed 
{
    // Code size 7 (0x7)
    .maxstack 8

    IL_0000: ldarg.0
    IL_0001: call instance void [mscorlib]System.Object::.ctor()
    IL_0006: ret
} // end of method .ctor

Я не мог не найти в IL причину, почему явное присвоение значений констант по умолчанию полям потребовало бы больше времени. Очевидно, компилятор C # действительно оптимизирует константы, и я подозреваю, что это всегда так.

Итак, тогда тест должен быть неправильным ... Я поменял местами содержимое классов A и B, поменял местами числа в строке результата и повторно запустил тесты. И о чудо теперь внезапно задание значений по умолчанию стало быстрее.

No init: 474,75    Init on Def: 464,42    Init in Const: 715,49
Method No init: 141,60    Method Init on Def: 171,78

^{(остальное)}

Поэтому я прихожу к выводу, что компилятор C # правильно оптимизирует тот случай, когда вы назначаете значения по умолчанию для полей. Никакой разницы в производительности!

Теперь мы знаем, что производительность действительно не проблема. И я не согласен с заявлением Рида Копси «« Дополнительный »код, даже если он был безвредным, предполагает, что он существует причина, которая снижает ремонтопригодность. "и согласны с Андерсом Ханссоном по этому поводу:

Подумайте о долгосрочном обслуживании.

• Сохраняйте код как можно более ясным.
• Не полагайтесь на языковые способы инициализации, если в этом нет необходимости. Может более новая версия языка будет работать иначе?
• Будущие программисты будут вам благодарны.
• Менеджмент будет вам благодарен.
• Зачем что-то запутывать даже в малейшей степени?

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

FxCop должен предоставить правила для всех, поэтому, если это правило вам не нравится, просто исключите его.

Теперь я бы посоветовал, если вы хотите явно объявить значение по умолчанию, используйте для этого константу (или статическую переменную только для чтения). Это будет даже яснее, чем инициализация значением, и FXCop не будет жаловаться.

private const int DEFAULT_AGE = 0;

private int age = 0; // FXCop complains
private int age = DEFAULT_AGE; // FXCop is happy

private static readonly DateTime DEFAULT_BIRTH_DATE = default(DateTime);

private DateTime birthDate = default(DateTime); // FXCop doesn't complain, but it isn't as readable as below
private DateTime birthDate = DEFAULT_BIRTH_DATE; // Everyone's happy

FX Cop считает, что добавление ненужного кода и ненужный код - это плохо. Я согласен с вами, мне нравится видеть, на что он настроен, я думаю, что это облегчает чтение.

Похожая проблема, с которой мы сталкиваемся, заключается в том, что по причинам документации мы можем создать пустой конструктор, подобный этому

/// <summary>
/// a test class
/// </summary>
/// <remarks>Documented on 4/8/2009  by richard</remarks>
public class TestClass
{
    /// <summary>
    /// Initializes a new instance of the <see cref="TestClass"/> class.
    /// </summary>
    /// <remarks>Documented on 4/8/2009  by Bob</remarks>
    public TestClass()
    {
        //empty constructor
    }        
}

Компилятор создает этот конструктор автоматически, поэтому FX Cop жалуется, но наши правила документации Sandcastle требуют, чтобы все общедоступные методы были задокументированы, поэтому мы просто сказали fx cop не жаловаться на это.

Он полагается не на то, что каждый программист знает какой-то локально определенный «корпоративный стандарт», который может измениться в любой момент, а на что-то формально определенное в Стандарте. С таким же успехом можно сказать «не используйте x++, потому что это зависит от знаний каждого программиста.

Вы должны помнить, что правила FxCop - это всего лишь рекомендации, их нельзя нарушить. Об этом даже говорится на странице описания упомянутого вами правила (http://msdn.microsoft.com/en-us/library/ms182274(VS.80).aspx, выделено мной):

Когда исключать предупреждения:

Исключите предупреждение из этого правила, если конструктор вызывает другой конструктор в том же или базовом классе, который инициализирует поле значением, отличным от значения по умолчанию. Также безопасно исключить предупреждение из этого правила или полностью отключить правило, если производительность и обслуживание кода не являются приоритетами.

Правило не совсем неверное, но, как говорится, для вас это не приоритет, поэтому просто отключите правило.