Joel on Software has posted reflections on the programming equivalent of defensive driving. In Making Wrong Code Look Wrong, Joel posits that certain design and convention practices promote defensive programming and overall QE...while others send you to a bad place fast.

Most successful development methodologies advocate "same page" conventions. The notion is that any reasonable approach works - just as long as everyone consistently uses it. So on that basis (and others) the kind annotation convention that Joel puts forth is fine.

But don't do it! Joel essentially suggests rich-typing design-time artifacts so that a reader (human or otherwise) easily identifies wrong code - where wrong code can be brittle, unsafe, etc. Such concerns are the realm of design patterns and AOP - not naming conventions and bracing styles. For example, when Joel talks about XSS vulnerabilities, this is a perfect place for the Chain of Responsibility pattern. I would suggest a re-read of the article with an eye on patterns. If you choose to use naming, then at least consider using Composite hierarchies instead of name-notation.

The core principle here is QE. And I could not agree more with Joel on its value. The importance of self-guiding, self-documenting code is something near and dear to me. I just do not see a few prefixes as a supportable pattern.

One more important tidbit from Joel's post is this:

Declare your variables as close as possible to the place where you will use them.

Years ago I learned and quickly adopted this practice. For some reason it is not favored by all. Greater minds than mine have preached its virtues though: maximizing scoping, code readability/review...but if you have a good reason against this practice I would love to hear it.