[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
请先登录再写评论。
Screenshots:
http://www.intellij.org/twiki/pub/Main/InspectThisPlugin/EmptyCatchBlock.jpg
http://www.intellij.org/twiki/pub/Main/InspectThisPlugin/RedundantInterfaceModifier.jpg
0.2 (#833) - Jun 22, 2003
- RFE Redundant interface modifiers.
JLS, "Chapter 9. Interfaces" ( http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html )
http://www.intellij.net/tracker/idea/viewSCR?publicId=7573 ("Redundant modifier warnings in interfaces")
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).
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...
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
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!"
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...
>
>
>
>
>
>
>
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
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
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