Passing unit tests are good. 100% code coverage is good. Continuous integration builds are good. But what happens when your IDE has a cool feature that lives outside of your automated tool suite?

Earlier this week, I was raising test coverage on some legacy Java Spring code. I usually commit changes from the command line, but I decided to use IDEA's svn integration instead. By default, this integration does some code review, reporting various hints. This is pretty cool, and it helped me find problem areas in the code. But the code review also poses a problem:

• How do I invoke these hints programmatically, so that I can include them in continuous integration?
• How do I overrule these hints on a case-by-case basis? This is incredibly important. If I could disable a hint in a particular location, I would open a whole universe of heuristic hints that are useful, but report too many false positives to simply run across the entire codebase.
• How do I track history? Overriding a hint should have a textual representation that goes into source control.

All IDE code-analysis functions should be exposed as services first, then skinned into the IDE interface. Wouldn't it be cool if the interfaces to these services were (even partially) standardized? Then we could share features across different IDEs. A good starting place for such standardization would be TextMate's elegant command model.

For Ruby, Tor Norbye is adding Ruby hints to NetBeans. Hopefully there will be some way to selectively enable such hints, scoped to specific regions of code.