We are using Microsoft FxCop to validate our code and the code above
unfortunatly violates Microsoft code guidelines. The rule says that it
is not allowed to call an overridable method in a constructor of a
class. The exact rule is
How do i have to do initialization to eliminate the violation? In your
example Demo1.exe initialization is done the same way as we do. So
there is a potential failure of initialization, too.
You don’t need to do such initialization in the constructor. You can easily do that in another method, whether that method is part of that class or in another class. So if you want to follow those guidelines, you can.
However, please understand that those code guidelines are only style guidelines. They are not requirements. Your code will compile and run correctly.
FxCop has been integrated into Visual Studio 2005. I have had long discussions with the FxCop engineers, complaining that some of their rules (although not this particular one) are misguided. Although they admitted the point in a number of cases, their general attitude was the same as what I just said: they are just coding guidelines, not requirements for implementing .NET code. They are supposed to help you find potential trouble spots.
After all, Microsoft’s own code does not, cannot, and will not meet the FxCop guidelines.
The bigger issue is that there may be organizations that decide to adopt FxCop/VS2005 coding style guidelines as requirements for all code development. I think it’s a good idea for everyone to occasionally run FxCop to notice potential bugs. However, any organization that mandates zero FxCop errors or warnings is doing itself a disservice. Requiring blind adherence to any coding standard is misguided. Coding standards are good, but everyone must apply rules judiciously and wisely. Automated systems such as FxCop, especially when integrated in Visual Studio, are more likely to cause wasted efforts and unnecessary conflict when people forget that they are just tools to help suggest where there might be potential bugs or difficulties in using an API.
I also think that some rules are misguiding e.g. ‘Compound words shoud
be cased correctly’. This rule does not really make sense.
But the description to the rule mentioned in my first post says:
‘… When a constructor calls a virtual method, it is possible that the
constructor for the instance that invokes the method has not executed.’
(www.gotdotnet.com)
And in ‘Practical Guidelines And Best Practises’ (Microsoft Press,
Authors: Francesco Balena, Guiseppe Dimauro) you’ll find in ‘15.17
Calling virtual methods from inside a constructor’ (Page 175):
'code in a constructor must not invoke a virtual method definded in the same type.
WHY: If you instantiate a derived class, the first thing that its
constructor does is invoke its base type’s constructor; if this
constructor invokes a virtual method and this method is overridden in
the derived type, the code in the method runs when the derived type’s
constructor hasn’t completed its execution and the type isn’t properly
initialized yet. This situation can lead to unexpected behaviors or
exceptions.’
And this does not seem to be just a style guideline but a serious
potential problem. I don’t know under which circumstances an erroneous
behaviour really occurs but if we are requested to omit to call a
virtual method in constructor it seems to be best to follow.
And we do not plan to lead our development to zero FxCop errors or
warnings. We know that even if it would be possible to do the effort’s
not worth it.
But let me come back to the initial problem ;-) I don’t think it is a
good way to separate constructor from initialization. So the creator of
an object would be responsible for initiliazation. Don’t you see
another way? Would it be practical to override properties (and setting
another default value with ‘[DefaultValue(true)]’ or better to override
‘Can’-Method? Or any other way?
Yes, that FxCop rule is a reasonable coding guideline, pointing out a real potential problem. However, it is only a real problem if the code is implemented in a manner that causes a bug. That can only happen in this case if the virtual method is overridden to depend on derived-class-only state. Presumably you haven’t done that with those virtual properties.
Which is why I don’t think there’s anything wrong with your code.
But it is quite normal for initialization to be done in a method separate from the constructor. For example, the constructor for GoIconicNode just creates an empty node. You need to call GoIconicNode.Initialize in order to give it an Icon (a GoImage) and a Label (a GoText) and a Port (a GoPort).