Re: Contributing SQE project to NB repository

On 01/18/2012 12:50 PM, Jan Lahoda wrote:
> we already have similar features (Analyze Javadoc, Inspect&Refactor), each bringing its own UI.

Analyze Javadoc is indeed similar in style. It is not clear to me that this functionality is better displayed in its own window, since I have never used this feature and 
do not know much about it - perhaps because, in its own window, it is much less discoverable than editor hints. What is the use case for this window? Just checking the 
whole tree and clicking Fix Selected would be pointless because then your source base would merely be filled with well-formed but empty Javadoc stubs; if you are really 
cleaning up Javadoc for a whole project you would want to jump to one warning, create a Javadoc skeleton either manually (e.g. "/**" and ENTER generates it) or by 
accepting an offer a fix, and complete the documentation of that member, before continuing to the next.

Inspect & Refactor feels different since it is usually used as a preview of an batch action, though you can also use it to aggregate warnings without particular fixes. 
That is, I would tend to use this window more to sanity-check a diff before clicking Refactor, and not so much to browse warnings.

> there apparently are other analysis tools, and allowing reasonable integration
> of them sounds like a good idea to me.

It is a matter of timing I guess. If there are several tools that get fitted into an API/UI for the same release, then we can be fairly confident that the API is useful 
(even if marked under development). If it is just FB in 7.2, then an API would probably be premature. FB provides some rather idiosyncratic information in its bug results 
- not just "X.java:123: some warning" but call chains, related occurrences, and HTML-formatted help.

The current UI in SQE provides some integration points such as running all tools with a single gesture. However it also creates a separate window for each tool, 
associated only via a TC group with another generic "control center" window. This feels pretty heavyweight for an IDE, though UIs of this kind are useful in CI server 
summary pages.

Checkstyle also has a lot of rules which are closer to "formatting" than "hints" in NB's terminology. In fact the maven.checkstyle module in the IDE distribution already 
lets you use a CS definition in the POM as the source of project-specific formatting conventions, so that Alt-Shift-F will more or less follow the CS rules.

PMD and CS also differ critically from FB in that they spew out vast numbers of warnings on existing code bases (few of which are indicative of likely bugs), so it is 
only reasonable to use them if you do so from the start on a new project, or disable most of their rules. This could affect how they are presented in the IDE.

SQE also bundles Dependency Finder but this is barely related to analysis tools.

> The static analysis could, at user's discretion, also be run before commit, complaining if the code got "worse".

You mean compared to the baseline version (hg parent, .svn/text-base/, etc.)? Tricky because you would need to restore that version from history (and in the case of FB, 
compile it). I think this kind of thing is better left to a CI server and Sonar.