[ANN] InspectionGadgets 0.0.7 released

Announcing version 0.0.7 of the InspectionGadgets plugin, available via the PluginManager
or at http://www.intellij.org/twiki/bin/view/Main/InspectionGadgets.

Changes in version 0.0.7

New Inspections

Overly coupled classes
Classes without package statement
Classes which reference their subclasses
Inner class on interface
Utility classes
Redundant "final" on "private" method
Redundant "final" on "static" method
Overly coupled methods
Methods with multiple loops
Implementation of finalize()
Negated if condition
Confusing else branch
Switch statements

plus lots of bugfixes

--Dave Griffith

26 comments

Redundant "final" on "private" method


Cool, thanks.

Tom

0

Running this for some code I received:

java.lang.NullPointerException
at com.siyeh.ig.classmetrics.CouplingVisitor.addDependency(CouplingVisitor.java:179)
at com.siyeh.ig.classmetrics.CouplingVisitor.visitMethod(CouplingVisitor.java:61)
at com.intellij.psi.impl.source.bc.accept(bc.java:43)
at com.intellij.psi.impl.source.p.acceptChildren(p.java:92)
at com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElementVisitor.java)
at com.intellij.psi.JavaElementVisitor.visitClass(JavaElementVisitor.java:41)
at com.siyeh.ig.classmetrics.CouplingVisitor.visitClass(CouplingVisitor.java:117)
at com.intellij.psi.impl.source.s.accept(s.java:278)
at com.siyeh.ig.classmetrics.ClassCouplingInspection.calculateTotalDependencies(ClassCouplingInspection.java:73)
at com.siyeh.ig.classmetrics.ClassCouplingInspection.access$100(ClassCouplingInspection.java:8)
at com.siyeh.ig.classmetrics.ClassCouplingInspection$ClassCouplingVisitor.visitClass(ClassCouplingInspection.java:55)
at com.intellij.psi.impl.source.s.accept(s.java:278)
at com.siyeh.ig.ClassInspection.checkClass(ClassInspection.java:21)
at com.intellij.codeInspection.g.i$0.visitClass(i$0.java:11)
at com.intellij.psi.impl.source.s.accept(s.java:278)
at com.intellij.psi.impl.source.p.acceptChildren(p.java:92)
at com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElementVisitor.java)
at com.intellij.psi.JavaElementVisitor.visitFile(JavaElementVisitor.java:170)
at com.intellij.psi.JavaElementVisitor.visitJavaFile(JavaElementVisitor.java:16)
at com.intellij.psi.impl.source.z.accept(z.java:30)
at com.intellij.codeInspection.g.i.a(i.java:8)
at com.intellij.codeInspection.g.p$4.visitJavaFile(p$4.java:4)
at com.intellij.psi.impl.source.z.accept(z.java:30)
at com.intellij.codeInspection.g.f.a(f.java:21)
at com.intellij.codeInspection.g.p.a(p.java:42)
at com.intellij.codeInspection.g.p.access$1400(p.java:103)
at com.intellij.codeInspection.g.p$23.run(p$23.java:8)
at com.intellij.openapi.application.b.b.runReadAction(b.java:286)
at com.intellij.codeInspection.g.p.c(p.java:194)
at com.intellij.codeInspection.g.p.access$300(p.java:193)
at com.intellij.codeInspection.g.p$19.run(p$19.java:1)
at com.intellij.progress.ProgressManager.runProcess(ProgressManager.java:34)
at com.intellij.openapi.application.b.b$0.run(b$0.java:1)

0

Woohoo, it's Christmas already!

Robbie

0


Yup, stupid bug. I'll be uploading 0.0.7.1 shortly.

--Dave

0

Does this version work in 977, too?


0

It's only been finally tested under 992, but was developed mostly under 977. Also, IG doesn't use any of the stuff that broke in the 977->992 update. That said, all I'm willing to commit to is that it will probably work. (If it doesn't, though, I'm extremely unlikely to do anything to fix it.)

--Dave

0

The plugin is invaluable, thanks a lot for the effort you put in building
and maintaining it.

I have a small bug report / feature request. I'm not sure if it's been
discussed before or if you intended the plugin to behave this way, so here
it comes. Say you have the following class:

public class A{
private String name1;
public static void doSmth(String name1){}
}

The "parameter hides member variable" inspection (in the visibility group)
tells me the parameter to the static method hides the member variable with
the same name. While I realize the names are clashing, the parameter cannot
really hide the field of the class, since the method is static.

Could you add yet another checkbox to the list of ignored name matches the
plugin finds?

Thanks,
Andrei

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:13208049.1071244796424.JavaMail.javamailuser@localhost...

Announcing version 0.0.7 of the InspectionGadgets plugin, available via

the PluginManager

or at http://www.intellij.org/twiki/bin/view/Main/InspectionGadgets.

>

Changes in version 0.0.7

>

New Inspections

>

Overly coupled classes
Classes without package statement
Classes which reference their subclasses
Inner class on interface
Utility classes
Redundant "final" on "private" method
Redundant "final" on "static" method
Overly coupled methods
Methods with multiple loops
Implementation of finalize()
Negated if condition
Confusing else branch
Switch statements

>

plus lots of bugfixes

>

--Dave Griffith



0


This has been brought up before, and it's certainly doable (not even tough, as that inspection already has boolean configuration itemes). However, I'm wondering if there's some sort of common idiom/pattern that I don't know about that causes this sort of clash. I haven't seen it myself, and I was just wondering if there was some circumstance where this issue often occurs.

--Dave Griffith

0

However, I'm wondering if there's some sort of common idiom/pattern that I
don't know about that causes this sort of clash. I haven't seen it
myself, and I was just wondering if there was some circumstance where this
issue often occurs.


Factory method, for instance? Although I've noticed it in other static
methods as well, so I'd rather have the setting recognize all the static
methods, not only factory ones.

Thx,
Andrei

0


Ah, that's the trick. I always make my factories separate classes, so no clash. Good enough. I'll add a switch.

--Dave

0

Sweet, thanks a lot.

Andrei


Ah, that's the trick. I always make my factories separate classes, so no
clash. Good enough. I'll add a switch.

--Dave


0

bummer I kind of liked 007 :)

Hey David, I've noticed that when there is only one result for a class, and there is a sugestion link to replace with what ever the suggestion is, if you click on that the change doesn't happen, the whole ide/inspection process just loses focus and there is no way out of it. Is this an inspection gadget problem, or is this a psi/ide/open api issue which has perhaps been reported already?

Thanks
R

0

Haven't seen it (or a tracker item for it), but if it exists it's an IDEA bug. All I provide using the Inspection API is the existence of a LocalQuickFix object, which IDEA then makes triggerable from up to four places. If it's not working in one of those places, and works in all the others, it's gotta be JetBrains bug.

--Dave

0

Announcing version 0.0.7 of the InspectionGadgets
plugin


When I install a new version of InspectionGadgets I have all new inspections disabled by default.
Than it is really difficult to find and enable the new ones among 200 others.

Is it just my system specific or everybody see this?

0


I have not seen this behaviour before. If anyone else has it, I'd appreciate a report. Are you installing via the Plugin Manager? Are you doing an uninstall first (you shouldn't)?

--Dave

0

Dave Griffith wrote:

I have not seen this behaviour before. If anyone else has it, I'd
appreciate a report.


Are you saying new inspections should be turned on by default? They
have always been turned off on my systems (at home and at work), and I
assumed this was intentional.

As a matter of fact I was about to request that new inspections could be
displayed in another color or something, or that you could split them
into groups in the announcement so that they would be easier to find.

0

Yes, I have installed it through PluginManager, without uninstalling previous version.
Currently I cannot report anything useful, because I have already configured the new version.

If you will release a new version I will give it a more thorugh look during updating.

Tell me please where the InspectionGadgets configuration is stored. I noticed one file:
config\options\editor.codeinsight.xml
are there any others

0

I believe that's the only place, but all of the configuration persistence is handled by JetBrains code, so there's no real way for me to be sure.

Thanks.

--Dave

0

OK, I tried this on my home machine,
I upgraded to 996 and than intalled your plugin.

Previously I copied the whole setup (whole IDE + whole project) from my office computer.

So previously I had settings configured for last InspectionGadgets in 6 series.

I made diff of files before and after plugin installation.
Results -
1. in file options\other.xml
we got new entry at the end
]]>

2. editor.codeinsight.xml file updated with new settings, all set to "DO_NOT_SHOW". See attached files.

One more thing - this behavior (new inspections disabled) started about release 963, but I am not so sure about it.



Attachment(s):
before_editor.codeinsight.xml
after_editor.codeinsight.xml
0

I seem to remember that there used to be a quick fix for the "Collection
declared by class, not interface". Now it is not offered anymore. Am I
doing something wrong?

Bas

0

There has never been such a quickfix, as I haven't yet coded up the logic to validate that the fix wouldn't make the code uncompilable. For instance, the inspection will always tell you that you should use "List" instead of "Vector", even if you use some of the methods on "Vector" that aren't on "List". If I could solve a few more dataflow equations, I would be able to create a safe quick-fix for locals, parameters, and even private class variables, but a safe quick-fix for method return types would require information which may not exist in the project

--Dave "Probably more information than you needed" Griffith

0

Using the quick fixes for the inspections "Object comparison using ==,
instead of .equals()" and "String comparison using ==, instead of
.equals()" on the following code inverts the conditions.

public class intentionTest {
public boolean test1(String s) {
return s != "foo";
}

public boolean test2(Object o) {
return o == new Integer(3);
}
}

Looks like line 57 in com.siyeh.ig.bugs.StringEqualityInspection and
line 62 in com.siyeh.ig.bugs.ObjectEqualityInspection are the problem.
The not equals (!=) in those if conditions should be equals (==).

And having an illegal character in a method name in the code above
produces the following exception. To reproduce type an @ after "test2".

Bas

2003-12-18 11:41:17,241 ERROR -
emon.impl.LocalInspectionsPass - Exception happened in local inspection
tool: Object comparison using ==, instead of '.equals()'
2003-12-18 11:41:17,251 ERROR -
emon.impl.LocalInspectionsPass - IntelliJ IDEA (Aurora) Build #996
2003-12-18 11:41:17,251 ERROR -
emon.impl.LocalInspectionsPass - JDK: 1.4.2_02
2003-12-18 11:41:17,251 ERROR -
emon.impl.LocalInspectionsPass - VM: Java HotSpot(TM) Client VM
2003-12-18 11:41:17,251 ERROR -
emon.impl.LocalInspectionsPass - Vendor: Sun Microsystems Inc.
2003-12-18 11:41:17,251 ERROR -
emon.impl.LocalInspectionsPass - OS: Windows 2000
2003-12-18 11:41:17,251 ERROR -
emon.impl.LocalInspectionsPass - Last Action: EditorRightWithSelection
2003-12-18 11:41:17,322 ERROR -
emon.impl.LocalInspectionsPass - Exception happened in local inspection
tool: Object comparison using ==, instead of '.equals()'
java.lang.NullPointerException
at
com.siyeh.ig.bugs.ObjectEqualityInspection$ObjectEqualityVisitor.visitBinaryExpression(ObjectEqualityInspection.java:150)
at com.intellij.psi.impl.source.d.a.f.accept(f.java:43)
at com.intellij.psi.impl.source.d.s.acceptChildren(s.java:56)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElementVisitor.java)
at
com.intellij.psi.JavaElementVisitor.visitStatement(JavaElementVisitor.java:33)
at
com.intellij.psi.JavaElementVisitor.visitReturnStatement(JavaElementVisitor.java:55)
at com.intellij.psi.impl.source.d.a.bh.accept(bh.java:1)
at com.intellij.psi.impl.source.d.s.acceptChildren(s.java:56)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElementVisitor.java)
at
com.intellij.psi.JavaElementVisitor.visitCodeBlock(JavaElementVisitor.java:46)
at com.intellij.psi.impl.source.d.a.br.accept(br.java:14)
at com.intellij.psi.impl.source.p.acceptChildren(p.java:21)
at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElementVisitor.java)
at
com.intellij.psi.JavaElementVisitor.visitClassInitializer(JavaElementVisitor.java:118)
at com.intellij.psi.impl.source.u.accept(u.java:9)
at
com.siyeh.ig.ExpressionInspection.checkClass(ExpressionInspection.java:24)
at com.intellij.codeInsight.k.a.i.a(i.java:53)
at com.intellij.codeInsight.k.a.bk$1.run(bk$1.java:2)
at com.intellij.openapi.application.a.b.runReadAction(b.java:338)
at com.intellij.codeInsight.k.a.bk.a(bk.java:3)
at com.intellij.codeInsight.k.a.bk.access$100(bk.java:15)
at com.intellij.codeInsight.k.a.bk$0.run(bk$0.java:1)
at com.intellij.progress.ProgressManager.runProcess(ProgressManager.java:1)
at com.intellij.codeInsight.k.a.bk.run(bk.java:10)

0

On 2003/12/18 11:59, Bas Leijdekkers wrote:

Looks like line 57 in com.siyeh.ig.bugs.StringEqualityInspection and
line 62 in com.siyeh.ig.bugs.ObjectEqualityInspection are the problem.
The not equals (!=) in those if conditions should be equals (==).


Those line numbers are based upon the source code that can be downloaded
from www.intellij.org, which doesn't seem to be entirely up to date I
see now...
To make it clearer:
if(sign.getTokenType() != PsiJavaToken.NE)
I think should be changed to:
if(sign.getTokenType() == PsiJavaToken.NE)

Bas

0

A minor bug: In the following class InspectionGadgets suggests that I
should weaken ArrayList]]> to null. If I remove the space within
the type declaration (which I'm going to do anyway) it correctly
suggests "List".

 foo;
}
]]>

0

I've got a fix, and it'll be in the next release. Thanks.

--Dave

0

Please sign in to leave a comment.