|
FxCop is a useful product, so it's nice to be able to link the new FxCop blog.
Moreover, a recent post provides a nice example of the tradeoffs related to using a DSL vs. opting for a more traditional design approach.
FxCop supports writing custom rules. Custom Rules can be written by writing a class in any.NET language. This class has to implement one of the interfaces FxCop provides via its SDK. After compiling the class into an assembly, FxCop can load the custom rule by pointing it to that assembly...FxCop doesn't really support editing the default rules right now.
Extensibility was an obvious design goal. Deciding to support extensions by providing hooks for user supplied code (what old timers called user exits, and others call frameworks etc.) is a standard (and often useful) design technique.
The price you pay, however, is that the user supplied code is less tightly integrated with your product, and it is harder to support things like editing, tracing etc.
An obvious solution is, of course, to supply a standard rule class, that invokes or implements an interpreter for a rules DSL. Then you can have all the advantages of a DSL, when you need them.
All these are common tricks. I am constantly surprised that only few programmers really master them.
Note: I am not trying to say that the FxCop guys don't know about all this. I just used their new weblog as an excuse to write about this issue...
Posted to Software-Eng by Ehud Lamm on 1/11/04; 2:44:20 PM
|
FxCop & DSLs
