I'm sitting here at work building an application using TDD (which by itself is another post, and may be coming later), and every time I start a new class for another piece of the puzzle, I'm hating on how I have put the keyword "sealed" class in my declaration. Now, this isn't a major issue, but it can be if you plan on releasing an API for customers to build against. What's my issue? Well, I'm wondering if the "sealed" and "notinheritable" keywords should be applied by default in Whidbey.
My proposition comes from the fact that it is good design practice to have your classes become "sealed" or "not inheritable", that way your users cannot accidently inherit and break changes with your API. In practice this is a big deal, and how often are you building an API, and you become lazy to allow the default attributes/keywords/accessors be applied to a API (classes specifically, making them public instead of private or internal/friend)? I'm almost betting very frequently.
I propose that in Whidbey, and future versions, that "sealed" or "not inheritable" be applied by default to all new class declarations created by the IDE. This way, you have to make an effort and think about what you're doing when removing this keyword, and hopefully make you think if you really need to do so.
As of right now, I realize that this can be accomplished by editing the templates used somwhere deep within the directory structure of VS.NET, so please don't tell me I can do this now. What are you're thoughts, feelings, objections to this?
efa7ec50-f865-472a-8161-59623529d64d|0|.0