То, почему FxCop думает, инициализируя поля к значению по умолчанию, плохо?
Вы сломали вещи, указав родственные имена на своих иностранных ключах в модели Puppy Order. Удалить те.
5 ответов
There can be significant performance benefits from this, in some cases. For details, see this CodeProject article.
The main issue is that it is unnecessary in C#. In C++, things are different, so many professors teach that you should always initialize. The way the objects are initialized has changed in .NET.
In .NET, objects are always initialized when constructed. If you add an initializer, it's possible (typical) that you cause a double initialization of your variables. This happens whether you initialize them in the constructor or inline.
In addition, since initialization is unnecessary in .NET (it always happens, even if you don't explicitly say to initialize to the default), adding an initializer suggests, from a readability standpoint, that you are trying to add code that has a function. Every piece of code should have a purpose, or be removed if unnecessary. The "extra" code, even if it was harmless, suggests that it is there for a reason, which reduces maintainability.
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 , выделено мной) :
Когда исключать предупреждения :
Исключить предупреждение из этого правила, если конструктор вызывает другой конструктор в том же или базовом классе, который инициализирует поле значением, отличным от значения по умолчанию. Также безопасно исключить предупреждение из этого правила или полностью отключить правило, если производительность и обслуживание кода не являются приоритетами .
Теперь правило не совсем неверно, но, как говорится, для вас это не является приоритетом, поэтому просто отключите правило.