[ANN] InspectionGadgets 0.0.3 released
Announcing the release of InspectionGadgets 0.0.3, for all your static analysis needs. Available at
http://www.intellij.org/twiki/bin/view/Main/InspectionGadgets, and requires Aurora build 896. If there are any problems, don't hesitate to let me hear 'em.
New Configuration Option
-
"InspectionGadgets error highlighting" toggle under the "Options" menu allows on-line error highlighting
to be quickly disabled. This is handy when looking at source code from others that has large numbers of errors
which you don't intend to fix.
New inspections
-
Unnecessary temporary object on conversion from basic type to String
Unnecessary temporary object on conversion from String to basic type
Object allocation in loop
Abstract method overrides abstract method
Instance variable not initialized by readObject
Class total cyclomatic complexity
Class inheritance depth
Class nesting depth
Class constructor count
Class field count
Class method count
New inspection options
-
"Local variable naming convention" inspection now has an option to ignore for-loop parameters.
"Local variable naming convention" inspection now has an option to ignore catch block parameters.
"Parameteter name hides instance variable" inspection now has an option to ignore parameters of setter methods.
"Parameteter name hides instance variable" inspection now has an option to ignore parameters of constructors.
"Local variable name hides instance variable" inspection now has an option to ignore variables not visible from the current scope.
"Parameteter name hides instance variable" inspection now has an option to ignore variables not visible from the current scope.
"Field names hides superclass field" inspection now has an option to ignore variables not visible from the current scope.
Inspection removed
-
The inspection for if/for/while/do-while statements whose body is not wrapped in {} has been removed,
now that IDEA has (finally) been extended to do this automatically via "Reformat Code".
Bug fixes
-
"Hardcoded File Separators" now ignores common date format strings (thanks to Vilya Harvey for this code).
Fixed bug where the "Parameter Naming Convention" and "Parameter hides instance variable" inspections
check catch block parameters, instead of just method parameters
Fixed bug where the "Local Variable Naming Convention" and "Local variable hides instance variable" inspections
do not check catch block parameters
Inspections dealing with collections classes now work with the com.sun.java.lang.util collection classes.
Fixed bug in "overridable method call in constructor" that incorrectly flagged constructor calls to "this" and "super".
"String literal as argument to .equals()" now works on .equalsIgnoreCase() as well.
"Abstract method overrides concrete method" fixed to work correctly with interfaces
请先登录再写评论。
Thanks for the update. Unfortunately, I'm still seeing warnings for local
variables with the same name as package-private fields in superclasses in a
different package, even though the new option is selected. :(
Dave Griffith wrote:
Bug: InspectionGadgets wants to convert "new
Double(string).doubleValue()" to "Double.valueOf(string)", but the first
expression returns a primitive double while valueOf returns a Double
object. Maybe you meant Double.parseDouble(string)?
Serves me right for not doing a full test on that feature. A new version (still marked 0.0.3) has been uploaded to the Wiki with this bug fixed.
Doh!!!
A new version (still marked 0.0.3) has been uploaded to the Wiki, which fixes this bug.
--Dave "This may be the stupidest bug I've ever coded" Griffith
Cheers!
By the way, sometimes I get this when I try to remove a modifier using the
intention. Don't know if its your side or not, but I thought I'd let you
know.
ERROR - mand.impl.CommandProcessorImpl -
ERROR - mand.impl.CommandProcessorImpl -
ERROR - mand.impl.CommandProcessorImpl - IntelliJ IDEA (Aurora)
Bui
ld #896
ERROR - mand.impl.CommandProcessorImpl - IntelliJ IDEA (Aurora)
Bui
ld #896
ERROR - mand.impl.CommandProcessorImpl - JDK: 1.4.2
ERROR - mand.impl.CommandProcessorImpl - JDK: 1.4.2
ERROR - mand.impl.CommandProcessorImpl - VM: Java HotSpot(TM)
Client
VM
ERROR - mand.impl.CommandProcessorImpl - VM: Java HotSpot(TM)
Client
VM
ERROR - mand.impl.CommandProcessorImpl - Vendor: Sun Microsystems
Inc
.
ERROR - mand.impl.CommandProcessorImpl - Vendor: Sun Microsystems
Inc
.
ERROR - mand.impl.CommandProcessorImpl - OS: Windows XP
ERROR - mand.impl.CommandProcessorImpl - OS: Windows XP
ERROR - mand.impl.CommandProcessorImpl - Last Action:
ShowIntentionAc
tions
ERROR - mand.impl.CommandProcessorImpl - Last Action:
ShowIntentionAc
tions
ERROR - mand.impl.CommandProcessorImpl - Current Command: Remove
modi
fier
ERROR - mand.impl.CommandProcessorImpl - Current Command: Remove
modi
fier
ERROR - mand.impl.CommandProcessorImpl -
java.lang.NullPointerException
at com.intellij.psi.impl.source.b.h.b(h.java:27)
at com.intellij.psi.impl.source.b.h.a(h.java:199)
at com.intellij.psi.impl.source.e.r.b(r.java:112)
at com.intellij.psi.impl.source.e.bh.delete(bh.java:44)
at
com.siyeh.ig.verbose.UnnecessaryInterfaceModifierInspection$Unnecessa
ryInterfaceModifersFix.applyFix(UnnecessaryInterfaceModifierInspection.java:
77)
at com.intellij.codeInspection.u.bk.invoke(bk.java:9)
at com.intellij.codeInsight.intention.b.bm.run(bm.java:7)
at com.intellij.openapi.application.a.d.runWriteAction(d.java:262)
at com.intellij.codeInsight.intention.b.bl.run(bl.java)
at com.intellij.openapi.command.b.b.executeCommand(b.java:26)
at com.intellij.codeInsight.intention.b.bu.run(bu.java)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at com.intellij.ide.s.a(s.java:42)
at com.intellij.ide.s.dispatchEvent(s.java:104)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Dave Griffith wrote:
Very nice plugin - I like it ;)
Border case that happens some times:
Inspection warning: Assignment to for-loop parameter j
The declaration of the j variable could be moved outside the for, but this would unnecessarily expose the variable.
Could for control variables not changed in the update part not have this warning?
Inspection warning: Package-visible field whatever
Offer intention to make field private.
Doing this right would require calling the "Encapsulate Field" refactoring, to create getters and setters and change any other classes to use them instead of direct variable access. I've got an open tracker item that would allow me to do that, but at present the API just doesn't seem to allow it.
--Dave Griffith
Yes, and for added coolness, do this in a smart way - e.g. check if anything
is relying on the field being visible, if so, do encapsulate field as
suggested, otherwise just privatise.
N.
Dave Griffith wrote:
>
But there's already a built-in inspection that will tighten up access if possible.
So is this available via InspectionGadgets then?
Dave Griffith wrote:
refactoring,
I was only hoping/asking for a dumb "Add private modifier to field
declaration" intention. If code doesn't compile after this (which I don't
mind), undoing the change is easy and the field can be encapsulated.
"Nathan Brown" <nedski@yahoo.com> wrote in message
news:bii9f7$mfg$1@is.intellij.net...
>
Didn't find it in the ide options->errors panel. Maybe it's available only
in the inspection action?
That would be trivially easy, but I really don't like the idea of creating uncompilable code via quick-fixes. Let me think about it.
--Dave
idea of creating uncompilable code via quick-fixes.
I don't much mind uncompilable code (I do very much mind changes that
compile but silently modify what the program does :-).
And in this case, the correction is going to the declaration and removing
the "private" modifier, so there's not much to undo .
Also, I haven't yet had a case where I was accessing a field directly. The
missing private modifier has crept in only in some inner classes accessed
mainly/only by the parent, so I haven't needed the encapsulate refactoring
:)
Adding the encapsulate refactoring if needed is the right thing to do, so
don't feel pressed to add this hack :) Writing "private" at the beginning
of the line is not too much work.
Carlos
I dont' understand why the following two array s are flagged as being octal and decimal.
Octal and decimal integers are in the same array initializer at line 110
private final static byte YY_ATTRIBUTE[] = {
1, 1, 1, 9, 1, 0, 0, 0, 1, 1, 1, 0, 9, 1
};
Octal and decimal integers are in the same array initializer at line 73
final private static int yy_rowMap [] = {
0, 4, 8, 12, 16, 8, 20, 24, 4, 28,
16, 32, 12, 24
};
Because I'm an idiot, and missed the special case of decimal arrays which contain "0". I'll put out a fix shortly.
--Dave Griffith
Some General Comments:
To get started with the inspections, I turned most of them on, and ran the inspection tool over the entire project. In the process of doing this I found the following things could be improved:
+ Inspection Tree
- The toplevel folders should be grouped together and the toplevel non-folders should be grouped together. [see inspection-groupedfolders.gif
- Within a Folder, the Inspections are not sorted by name.
+ Inspection Results Tree
- IMO the auto-scroll-to-source button should be on by default. I think most people what to see the editor display the source code when a results item is clicked.
- The auto-scroll-to-source just jumps to the 'Location' as listed in the detail pane; It doesn't jump to the first item under 'Problem Synopsis'
- The Results Tree should fully expand all locations to show all items instead of listing a location once with number of items (10 items). I shouldn't have to goto the detail pane to get to each problem. It should all be accessible from the results tree on the left-hand-side. The way it works now is non-intuitive. Imagine if it worked like this for compiler errors, e.g. on th left-hand-side it lists a method (7 errors), and then you have to click on it, then goto the right-hand-side to find each of the errors.
- One problem I had when I was experimenting is that I would find some of the inspections I wanted to turn off, but it took me awhile to track down the inspection in the Inspection Tool dialog. The following enhancements would be this easier to do:
- Somewhere in the results, the folder name should be displayed. That would make it much easier to find the inspections. The panel title, e..g 'Inspection - Assignment to method parameter' should say 'Inspection - Potentially confusing code constructs - Assigment to method parameter'
- Ideally, I would like a button in the Inspection Tool window 'Edit Inspection' which would popup the Inspection Tool Dialog and autoselect the current inspection, so I can either edit the parameters for the inspection or disable the inspection.
- The 'Apply an inspection quickfix' lightbulb icon is enabled even if no quickfix was available. If you click the icon, a popup menu just says 'Accept Resolution'. If you click it, it causes an IDEA Internal Error.
- I would prefer to do away with the tabs, and just make each tab a toplevel folder in the results tree.
Attachment(s):
inspection-groupfolders.gif
inspection-autosort.gif
inspection-toomany-tabs.gif
>To get started with the inspections, I turned most of >them on, and ran the inspection tool over the entire >project.
A tempting plan, but likely to overwhelm you.
I like a lot of your suggestions, and am unsure about others, but they are all things that have to be done by JetBrains, not me. Best to issue a whole bunch of Tracker items.
ok, will do
All of your notes do concern IDEA inspection API implementation rather than
InspectionGadgets plugin. Please do post them into tracker. Many of them
(like grouping suggestions) are more than discussable IMO though.
--
Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
"Alex" <no_mail@jetbrains.com> wrote in message
news:31515322.1062007484171.JavaMail.itn@is.intellij.net...
>
inspection tool over the entire project. In the process of doing this I
found the following things could be improved:
>
non-folders should be grouped together. [see inspection-groupedfolders.gif
inspection-sorted.gif ]
>
>
most people what to see the editor display the source code when a results
item is clicked.
>
the detail pane; It doesn't jump to the first item under 'Problem Synopsis'
>
instead of listing a location once with number of items (10 items). I
shouldn't have to goto the detail pane to get to each problem. It should all
be accessible from the results tree on the left-hand-side. The way it
works now is non-intuitive. Imagine if it worked like this for compiler
errors, e.g. on th left-hand-side it lists a method (7 errors), and then you
have to click on it, then goto the right-hand-side to find each of the
errors.
>
of the inspections I wanted to turn off, but it took me awhile to track down
the inspection in the Inspection Tool dialog. The following enhancements
would be this easier to do:
>
would make it much easier to find the inspections. The panel title, e..g
'Inspection - Assignment to method parameter' should say 'Inspection -
Potentially confusing code constructs - Assigment to method parameter'
>
Inspection' which would popup the Inspection Tool Dialog and autoselect the
current inspection, so I can either edit the parameters for the inspection
or disable the inspection.
>
no quickfix was available. If you click the icon, a popup menu just says
'Accept Resolution'. If you click it, it causes an IDEA Internal Error.
>
toplevel folder in the results tree.
>
"Please do post them into tracker". Then you should probably make changes at http://www.intellij.org/twiki/bin/view/Main/InspectionPlugins ("API uses PSI(ProgramStructureInterface) and thus is "open" at the same terms.") or http://www.intellij.org/twiki/bin/view/Main/ProgramStructureInterface ("Please note that PSI is not a part of official openapi. So you shouldn’t: - Fill in SCRs about PSI – it’s totally unsupported by now.")?
Timur
No, because he's not suggesting changes to the OpenAPI. He's suggesting changes to the inspection panel.
My understanding is that it's not ok (at least according to web pages I mentioned) to file SCRs regarding suggested implementation changes of semi-open API.
"Then you should probably make changes ..."
I think the policy needs to be updated. People are posting questions regarding semi-open APIs to newsgroups anyway (it's just more convenient). JetBrains programmers ask for feedback, questions (and very promptly address them) for just released semi-open API (intention, inspection, testing framework).
I think there should be no restrictions on posting any questions at the newsgroups/forums (it's impossible to enforce any restrictions anyway). Also it should be ok to file any SCRs. The policy could be that it's not guaranteed that it will be addressed at all by JetBrains. See also http://www.intellij.net/tracker/idea/viewSCR?publicId=13355#507361 (I agree with Jacques).
Timur
Feature Requests:
#15459- Tools->Inspect Code->Inspections Panel should sort the inspections
#15461- Tools->Inspect Code, Inspections Results Tree enhancements.
#15463- Tools->Inspect Code, Inspections Results Window enhancements.
Bugs
#15464- Tools->Inspect Code, Inspections Results Window, IDEA Internal Error if no quickfix
All the problems (?) Alex had mentioned concerns IDEA's own inspections as
well as Dave's ones. In any case almost every functionality in IDEA is
implementation of PSI or its usage. Will this prevent you from submitting
feature requests against those functionalities?
--
Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
"Timur Zambalayev" <no_mail@jetbrains.com> wrote in message
news:2184024.1062016761774.JavaMail.itn@is.intellij.net...
mentioned) to file SCRs regarding suggested implementation changes of
semi-open API.
java.lang.NullPointerException
at com.siyeh.ig.psiutils.ClassUtils.inSamePackage(ClassUtils.java:87)
at
com.siyeh.ig.visibility.LocalVariableHidingMemberVariableInspection$LocalVar
iableHidingMemberVariableVisitor.checkFieldName(LocalVariableHidingMemberVar
iableInspection.java:156)
at
com.siyeh.ig.visibility.LocalVariableHidingMemberVariableInspection$LocalVar
iableHidingMemberVariableVisitor.visitLocalVariable(LocalVariableHidingMembe
rVariableInspection.java:96)
at
com.intellij.psi.impl.source.tree.java.PsiLocalVariableImpl.accept(PsiLocalV
ariableImpl.java:207)
at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)
at
com.intellij.psi.JavaElementVisitor.visitStatement(JavaElementVisitor.java:2
49)
at
com.intellij.psi.JavaElementVisitor.visitDeclarationStatement(JavaElementVis
itor.java:75)
at
com.intellij.psi.impl.source.tree.java.PsiDeclarationStatementImpl.accept(Ps
iDeclarationStatementImpl.java:31)
at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)
at
com.intellij.psi.JavaElementVisitor.visitCodeBlock(JavaElementVisitor.java:5
9)
at
com.intellij.psi.impl.source.tree.java.PsiCodeBlockImpl.accept(PsiCodeBlockI
mpl.java:78)
at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)
at
com.intellij.psi.JavaElementVisitor.visitStatement(JavaElementVisitor.java:2
49)
at
com.intellij.psi.JavaElementVisitor.visitBlockStatement(JavaElementVisitor.j
ava:39)
at
com.intellij.psi.impl.source.tree.java.PsiBlockStatementImpl.accept(PsiBlock
StatementImpl.java:39)
at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)
at
com.intellij.psi.JavaElementVisitor.visitStatement(JavaElementVisitor.java:2
49)
at
com.intellij.psi.JavaElementVisitor.visitForStatement(JavaElementVisitor.jav
a:127)
at
com.intellij.psi.impl.source.tree.java.PsiForStatementImpl.accept(PsiForStat
ementImpl.java:120)
at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)
at
com.intellij.psi.JavaElementVisitor.visitCodeBlock(JavaElementVisitor.java:5
9)
at
com.intellij.psi.impl.source.tree.java.PsiCodeBlockImpl.accept(PsiCodeBlockI
mpl.java:78)
at
com.intellij.psi.impl.source.TreeWrapperPsiElement.acceptChildren(TreeWrappe
rPsiElement.java:63)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)
at
com.intellij.psi.JavaElementVisitor.visitMethod(JavaElementVisitor.java:175)
at
com.intellij.psi.impl.source.PsiMethodImpl.accept(PsiMethodImpl.java:255)
at com.siyeh.ig.MethodInspection.checkMethod(MethodInspection.java:27)
at
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.collectInformation
(LocalInspectionsPass.java:78)
at
com.intellij.codeInsight.daemon.impl.UpdateThread$2.run(UpdateThread.java:13
7)
at
com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(Applicat
ionImpl.java:343)
at
com.intellij.codeInsight.daemon.impl.UpdateThread.doRun(UpdateThread.java:12
9)
at
com.intellij.codeInsight.daemon.impl.UpdateThread.access$100(UpdateThread.ja
va:15)
at
com.intellij.codeInsight.daemon.impl.UpdateThread$1.run(UpdateThread.java:11
5)
at
com.intellij.progress.ProgressManager.runProcess(ProgressManager.java:110)
at
com.intellij.codeInsight.daemon.impl.UpdateThread.run(UpdateThread.java:111)
--
Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:17038588.1061822154221.JavaMail.itn@is.intellij.net...
analysis needs. Available at
requires Aurora build 896. If there are any problems, don't hesitate to let
me hear 'em.
>
allows on-line error highlighting
others that has large numbers of errors
>
>
>
for-loop parameters.
catch block parameters.
ignore parameters of setter methods.
ignore parameters of constructors.
to ignore variables not visible from the current scope.
ignore variables not visible from the current scope.
ignore variables not visible from the current scope.
>
wrapped in {} has been removed,
"Reformat Code".
>
to Vilya Harvey for this code).
instance variable" inspections
hides instance variable" inspections
com.sun.java.lang.util collection classes.
flagged constructor calls to "this" and "super".
as well.
interfaces
>
My understanding was that the spirit of the policy was: don't file SCRs regarding issues caused by plugins using semi-open API. So if I can repro/have the issue without any plugins using semi-open API, I can certainly file the issue. If it's caused/exposed by a plugin using semi-open API, I cannot (at least that was my understanding of the policy).
Timur
I guess, based on this read, that you might have a point. The "problem" these items are trying to address is that the Inspections GUI (not the API) doesn't beautifully scale to handle 180 different inspection types, although it handles the 15 or so built-in inspections well enough. Is this then an issue "caused" by the plugin, or an pre-existing issue "exposed" by the plugin? I'd vote the latter, and say that those fit the policy, but could see the argument. Apologies if my suggestions broke policy. I try never to do that by accident (preferring to save up karma for when I have to do it on purpose).
--Dave Griffith