So, I’m sitting here listening to Richard Hale Shaw talk about better class design, CLS compliance, and FxCop, among other things.
I guess I’m writing a brief overview of the talk, complete with my own comments on the content. Kdeep in mind that this is a stream of consciousness post, so expect sudden stops, spelling mistakes, typos, and lost of unfinished business…
CLS compliance is all about what you expose outside of your assembly, not the private interface.
- Create consistent usage: delegates 1st param sender, 2nd param e
use specific suffixes for certain types, such as “Attribute”, “Collection”, “Exception”. etc. MyException, etc.
some prefixes and suffixes to avoid, like Delegate, Enum, Before, After. I;m not sure I agree with this one.
_btnMine, _cboMembers, leading underscore and common type prefixes. Underscores show up first when you use intellisense. Possibly a plus. The acronyms help group the items within the Intellisense UI.
Base classes have some advantages in that you can version them and free the deriver from the problems that would otherwise follow. This is interesting and requires more investigation.
The reflection stuff is cool… and easy… lots of cool ways to exploit it.
Use static classes instead of creating a regular class with all static methods. This is new for C# 2.0. This is perhaps an alternative for cases where you might want to use sealed. Again, I need to re-read this stuff since I’m not sure when I’d use one or the other.
Richard went into quite a bit of detail when he described the differences between Value types and Reference types. He presented lots of his own guidelines and guidelines that he’s gathered. For instance, ValueTypes are useful when yoiu have many of them, lifetime is short, and they are relativelky small, say 16 bytes or less. Boxing and unboxing is an issue with ValueTypes. His rule of thumb is to write most types as reference types and prototype and look for hotspots. Only change to ValueType when there is a performance bottleneck.
Brute force casts are evil (necessary for ValueTypes) but everyone should prefer as and is keywords. Static casts bypass the compiler and force cast exceptions at runtime, which is really bad.
Checked exceptions, not a good idea. They are in Java, but they are enormously cumbersome and stick on poor performance. The as keyword will simply return null, like C++ dynamic_cast (when RTTI is enabled). You can check for it (efficiently) and move on…
Here’s an interesting one. Avoid properties that return arrays. They look like indexers, but aren’t indexers. The returned array is a copy and has no built-in semantics. I’ve never written an indexer property, though I know the basic idea, so some experimentation is in order. Do you see a common theme here?
Delegates vs. Event objects. Hmmm. I missed some of the details on his point here, when to avoid delegates. I’ll have to talk to him afterwards to resolve this.
Looks like Richard Hale Shaw went over, so things are closing down quite abruptly. I’ll be thinking about a lot of this stuff and I hope to post followup posts.
Comments on any of this are welcome.
Posted by Nick Codignotto at March 25, 2004 08:59 PM | TrackBack