I am not sure that I agree with his division. From my point of view, demo code need to focus on one single aspect, mostly because we are going to talk around that, and doing that means that I don’t have the time to deal with anything but the aspect that I need to talk about.
Sample code is a more fleshed out example.
I don’t make any distinction between reference and sample apps, maybe the size is different but that is about it.
What is important to follow is that for all of them, except maybe prototype (and I was bitten by that before), I have the same code quality expectations.
Note that I am saying code quality vs. production readiness. Most of the code that you see in demos or sample apps is not production ready. And that is fine.
Production readiness include such things as:
- Parameter validation
- Error handling
- Failover & recovery
And a lot more “taxes” that we need to deal with.
That does not include code quality. Code quality is a metric of its own, and it is one that you cannot give up. I would be personally ashamed to put out something that didn’t meet my own code quality metrics.
Sometimes, being production ready means that you have to give up on code quality, here is one example, that is understood and acceptable in certain circumstances.
What is not acceptable is to say that this is “Xyz” type of code sample, therefore code quality doesn’t matter.
And code quality isn’t really some amorphous thing. It is a very well defined metric that can be automatically checked. FxCop or NDepend are good tools to have, Simian will give you a lot of value all on its own.
When you put something out as an official Microsoft guidance release, the bar is higher, because whatever you do will be used by other people.