How to find methods that should be moved?

I can't seem to find an inspection to find methods which should be
moved. I generally build up static utility classes with lots of static
methods, but then some of them end up only being used by one class, or
in one class hierarchy, or in one package. How can I find these easily
(among the dozens of static methods) and hopefully move them automatically?

8 comments

That's an early global inspection I'll be adding to InspectionGadgets, as soon as I figure out the (really shockingly difficult) global inspections API.

--Dave Griffith

0

Hello Dave,

DG> That's an early global inspection I'll be adding to
DG> InspectionGadgets, as soon as I figure out the (really shockingly
DG> difficult) global inspections API.

Anything we can do to make it less shockingly difficult? :)

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

I haven't really looked at the global inspections api yet, but I've just
coded up an "Static method only used from one other class" (local)
inspection. This will be available in the next EAP build.
No quick fix yet however, as I don't see an easy way to implement that.

Bas

Dave Griffith wrote:

That's an early global inspection I'll be adding to
InspectionGadgets, as soon as I figure out the (really shockingly
difficult) global inspections API.

--Dave Griffith

0

By the way, starting a request for cutting-edge, not-available-in-any-commercial-product code analysis technology with "I can't seem to find" made me smile. Either it was wonderfully understated humor, or you really do expect this tool to have omniscience, omnipotence, and four-wheel drive. Patience, young padawan, we're getting there.

--Dave Griffith

0

Right now, I'm still trying to figure out I just don't understand it or if it's actually broken in some small but important ways. The sample helps (telling me about an entire analysis pass that I didn't know about, for instance), but seems to be broken itself.

http://www.jetbrains.net/jira/browse/IDEA-7250

http://www.jetbrains.net/jira/browse/IDEA-7251

--Dave Griffith

0

Should just be a matter of triggering a Move refactoring, I would think. I mostly tried to avoid doing local inspections that required global reference searches, as they have had poor performance characteristics during editing. Maybe the caching has improved to the point where that's no longer the case?

--Dave Griffith

0

Dave Griffith wrote:

Should just be a matter of triggering a Move refactoring, I would
think.


I'll see what I can do. Just showing the refactoring dialog doesn't seem
very useful to me, but perhaps it's better than nothing.

I mostly tried to avoid doing local inspections that required
global reference searches, as they have had poor performance
characteristics during editing. Maybe the caching has improved to
the point where that's no longer the case?


Inspection that do reference searches are indeed the most expensive. In
this case at most two references per static method are processed. A
(utility) class would need a lot of static methods to significantly
impact inspection time.
Currently IntentionPowerPack is taking up quite a bit of cpu and I have
been meaning to fix that for quite some time. I haven't yet gotten round
to it though.

Bas

0

+Just showing the refactoring dialog doesn't seem
very useful to me, but perhaps it's better than nothing.+

In a perfect world, it would be like the renaming quickfixes, popping up a pre-populated refactoring dialog, that the user could edit or approve with a keystroke.

If that's not doable with the current API, I'll submit a request. Once I understand the global inspection API, I'll need to be able to cleanly trigger moves of all sorts of stuff.

--Dave Griffith

0

Please sign in to leave a comment.