[ANN] InspectThisPlugin-0.1 released

http://www.intellij.org/twiki/bin/view/Main/InspectThisPlugin

http://sourceforge.net/projects/tz-ip/

Works only with #833. Please note that the next build will break the plugin - http://www.intellij.net/forums/thread.jsp?forum=23&thread=33177 .

0.1 (#833) - Jun 22, 2003

- RFE Empty catch block.

Effective Java by Joshua Bloch ( http://java.sun.com/docs/books/effective/toc.html ). Item 47: Don't ignore exceptions.
http://www.intellij.net/tracker/idea/viewSCR?publicId=9286 ("New inspection: look for 'swallowed' exceptions")
http://www.intellij.net/tracker/idea/viewSCR?publicId=12189 ('"Yellow line" warning on empty catch clause')


Timur

9 comments
Comment actions Permalink

Screenshots:
http://www.intellij.org/twiki/pub/Main/InspectThisPlugin/ModifiedParameter.jpg
http://www.intellij.org/twiki/pub/Main/InspectThisPlugin/EmptyBlock.jpg

0.3 (#833) - Jun 23, 2003

- Bug Misses some empty catch blocks: {}.
- RFE Modified parameter inspection.
- RFE Empty block inspection (then, else, finally, etc).

0
Comment actions Permalink

This is all very cool, but are you going to get annoyed when I release the plugin I promised which includes these inspections (along with about 130 others)? I'm about half done with the detection and auto-fix logic for them, and will be polishing up the UI with the next Aurora release (assuming they get their API polished). I had already done the 4 inspections you list, and don't really feel like pulling them out...

0
Comment actions Permalink

Dave,

No, not at all (of course). I know that you're working on the plugin and that you already implemented many inspections. I was just playing around with the API, implemented some inspections and decided to share them.

BTW, thank you for asking to open the Inspection API!


Timur

This is all very cool, but are you going to get
annoyed when I release the plugin I promised which
includes these inspections (along with about 130
others)? I'm about half done with the detection and
auto-fix logic for them, and will be polishing up the
UI with the next Aurora release (assuming they get
their API polished). I had already done the 4
inspections you list, and don't really feel like
pulling them out...


0
Comment actions Permalink

along with about 130 others


Seems inspection UI should somehow be changed under this massive attack.
Imagine 130+ tabs open in Inspection tool window.
Any constructive ideas?


--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"



0
Comment actions Permalink

Since the inspection options dialog groups the inspections and shows them in
a tree, why not present the results the same way? Three cells in the
inspection pane might not look that bad.

Andrei

"Maxim Shafirov" <max@intellij.net> wrote in message
news:bd7i9a$itb$1@is.intellij.net...

along with about 130 others

>

Seems inspection UI should somehow be changed under this massive attack.
Imagine 130+ tabs open in Inspection tool window.
Any constructive ideas?

>
>

--

>

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"

>
>
>


0
Comment actions Permalink

We could also merge the results from the inspections (we already filtered them before running the inspection). But if we want to filter the results based on the inspection type we could have a special tab for this, it could be a tree-like structure with checkboxes as nodes (like the panel you have before running the inspections) with actions like SelectAll, SelectOnlyThisNode, SelectOnlyThisGroup.

Also currently we have only 2 levels (e.g. level one: "Declaration Redundancy" group, level two: "Empty method"). Probably we need now 3 levels (level one: plugin level or a supergroup, so that we can disable all plugin/supergroup inspections, level two: groups within a plugin, level three: nodes).


Timur

0
Comment actions Permalink


I doubt it would happen very often. If you're running inspections at all, it's presumably for the purpose of fixing any errors found, so having huge numbers and kinds of outstanding errors should only happen when you try to run a massive inspection on an existing code-base. Also, many of these inspections are either useful only to a fraction of applications (i.e. internationalization, serialization) or will only happen infrequently ("Long literal ending with l", "Assignment to for-loop variable", "hashCode() misspelled as "hashcode()"). Looking over the provided inspections and my additions, I can barely imagine a legacy application needing 80 inspection tabs, which seems like it would be doable from a UI perspective, if perhaps unsightly. I'll try to keep my tab names as short as possible (so that more tabs fit in a given patch of real-estate). I'll also merge similar inspections into one ("for statement with empty body" and "while statement with empty body", for instance), possibly with configuration information to differentiate. I could get by with one "naming conventions" inspection, rather than a dozen, for instance, and still cover the same functionality.

The largest commercial static analysis product out there is JTest, which claims 300 inspections. If you look over the list, however, a lot of them are either code-formating (a quick Ctrl-Alt-L removes the need for), metrics-based (which I'm avoiding, although someone else might not), or overly fine-grained (your "declaration access can be weaker" inspection covers six of their inspections, your "unused declaration" eight, your "javadoc problems" more than twenty!). With proper generalization, I could probably cover that functionality, along with that in Bugseeker, Checkstyle, TogetherJ Audits, and JDeveloper CodeCoach (no, I'm not aiming small) with no more than 100 inspections beyond the core set provided. While I don't doubt someone will be able to think of a handful of inspections that I've missed, there's just not a whole lot that's already
been thought of that I'm not planning on doing.

All that said, if 130 inspection tabs scares you, it's probably worth starting to think about other UI formats.

--Dave

0
Comment actions Permalink

Since the code problems may be grouped by heaviness, the results may be filtered/grouped in the same manor. Let the user define the level of each the inspection detail. Finally the user should be able to soft/filter the results by level and as much as possible automatice solutions should be applyable (with/without dialog).
The defintion of the inspection elements defines the way to present the results, but the results should be presented in an overview (maintainable with as less as possible clicks). Therefore I guess a list/tree should be the best approach.

Sven

0

Please sign in to leave a comment.