<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 17, 2009, at 7:02 AM, Ben Laurie wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">On Sat, Jan 17, 2009 at 2:53 PM, Monty Zukowski <<a href="mailto:monty@codetransform.com">monty@codetransform.com</a>> wrote:<br><blockquote type="cite">I'm glad to hear all the details of your analyzer. I'll have more<br></blockquote><blockquote type="cite">questions later, I'm sure, but for now this is what interests me most:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Another high-level goal of the analyzer is to support the relaying of rich<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">diagnostics to end-users about how a bug manifests in their program. The<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">diagnostic reporting mechanism in the analyzer also uses a set of abstract<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">interfaces so that bug reports can be rendered in a variety of ways (e.g.,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to the console, to an HTML page, within an IDE, etc.). Providing rich<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">diagnostics is an important goal because without them the results of a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">static analysis algorithm is only useful to graduate students studying<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">program analysis techniques rather than programmers who want to fix bugs.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As you mentioned later, issue tracking is very important and the<br></blockquote><blockquote type="cite">analyzer can be designed to help with that.<br></blockquote><br>I do wonder if suppression of false positives is better done by<br>annotation than by tracking...<br><br>a) The annotation can be reused by other analysers.<br><br>b) The annotation works for developers who start from scratch.</span></blockquote></div><br><div>I personally like annotations. They represent "actionable documentation" that can be leveraged by multiple tools.</div><div><br></div><div>That said, in my own conversations with different developers I have seen cases where annotations directly in the source code are completely taboo. Probably the best example is source code that is under a tight "change control" process where only critical changes can be made to the source code. Being able to "annotate" code, be it for issue tracking or enhancing a tool's knowledge of the code, without actually *modifying* the code is really useful in such circumstances. This allows code to be actively scanned and "annotated" without source modifications. Alternatively, one may wish to back-scan previous versions of a code base to determine when certain issues appeared. Earlier versions of a code base wouldn't certainly lack any annotations embedded in the code itself.</div><div><br></div><div>That said, source-level annotations are the easiest to support (from an engineering perspective) and probably most accurate form of documentation.</div></body></html>