Idea for new inspection?

To catch a situation I just had, I created a Collection as a local
variable, called one of it's mutators, but then did nothing with it when
I should have passed it into another method. But I had no warning that
what I'd done was useless.

So to formalize the request, is there any way to flag a Collection
constructed within a scope whose mutator interface methods are called
without the accessor interface methods being called (or vice versa)
within the scope of the variable? Obviously there should be no flag if
the Collection reference is passed out of the current scope by method
call or return value (or this should be configurable maybe) as I guess
it can only be assumed it is properly used by the caller/callee.

Hope this isn't sounding like a too specific case, just thought I'd
brain dump it in case there's something valuable in there; I think it's
a natural companion to the "field assigned but not accessed" warning.
I'm also thinking it applies equally to arrays too.

Cheers,
Nathan.

3 comments
Comment actions Permalink

+So to formalize the request, is there any way to flag a Collection
constructed within a scope whose mutator interface methods are called
without the accessor interface methods being called (or vice versa)
within the scope of the variable?+

Already exists, at least in the Irida EAPs. It's called "Mismatched query and update of collection", and is my personal favorite inspection ever.

+
Obviously there should be no flag if
the Collection reference is passed out of the current scope by method
call or return value (or this should be configurable maybe) as I guess
it can only be assumed it is properly used by the caller/callee.
+

Already covered. If you pass the collection reference in or out, or assign the collection reference to a different collection variable, it is assumed to be both written and read. Additionally, update methods where you read the result returned count as reads, or at least will in the next EAP.

+
I think it's
a natural companion to the "field assigned but not accessed" warning.
+

Exactly. Both find the cases where a required implicit duality is broken. There are other inspections like that ("Unused *" , error handling exceptions, "Resource opened but not closed."), and they tend to be very powerful. I'm always on the lookout for them. Programming only works if you close all the loops.

I'm also thinking it applies equally to arrays too.

"Mismatched read and write of array" does what you want, although it's got some bugs to work out in the case of multi-dim arrays.

--Dave Griffith

0
Comment actions Permalink

Wow, so it is... and casting my eye over the list, so are a slew of
other cool inspections! I should have known better really shouldn't
I... Seems a lot have gone in as part of Irida development without me
realising. I guess I've been spoilt by those halcyon days when each of
your IG releases enumerated every single new addition to this great
plugin. What's the best way to keep informed of new inspections these
days? Is there a single JIRA issue somewhere that covers new inspections?

Cheers again Dave.

N.

Dave Griffith wrote:

+So to formalize the request, is there any way to flag a Collection
constructed within a scope whose mutator interface methods are called
without the accessor interface methods being called (or vice versa)
within the scope of the variable?+

Already exists, at least in the Irida EAPs. It's called "Mismatched query and update of collection", and is my personal favorite inspection ever.

+
Obviously there should be no flag if
the Collection reference is passed out of the current scope by method
call or return value (or this should be configurable maybe) as I guess
it can only be assumed it is properly used by the caller/callee.
+

Already covered. If you pass the collection reference in or out, or assign the collection reference to a different collection variable, it is assumed to be both written and read. Additionally, update methods where you read the result returned count as reads, or at least will in the next EAP.

+
I think it's
a natural companion to the "field assigned but not accessed" warning.
+

Exactly. Both find the cases where a required implicit duality is broken. There are other inspections like that ("Unused *" , error handling exceptions, "Resource opened but not closed."), and they tend to be very powerful. I'm always on the lookout for them. Programming only works if you close all the loops.

I'm also thinking it applies equally to arrays too.

"Mismatched read and write of array" does what you want, although it's got some bugs to work out in the case of multi-dim arrays.

--Dave Griffith

0
Comment actions Permalink

+Seems a lot have gone in as part of Irida development without me realising. +

I haven't been slacking. To be honest, mostly I get inspection ideas from competing commercial and open-source product announcements (that's cool, they watch what I'm doing as well), and there seems to been a bit of a burst recently from a few of them (FindBugs, Instantiations CodePro, and Parsoft JTest). I think I've pretty much caught up with the inspections of theirs that I want to implement, and their ideas have spurred me to come up with some more as well, also largely implemented. I expect the velocity will decrease from here through the end of the Irida cycle, except for a handful of JSP/Servlet-oriented inspections I'll be implementing.

BTW, you and I came up with the "mismatched" inspections from scratch. No one else has those yet. Give it another week, and I wouldn't be surprised to see it in a FindBugs announcement. Those guys are nearly as fierce as I am about incorporating new rules, even if they are using the wrong tools for the job.

+
What's the best way to keep informed of new inspections these days?
+

Umm, periodically scroll through the "Errors" panel and see what's new. For all the squawking I've done about JetBrains not announcing features, I've gotten quite slack about announcements since IG become folded into the shipped product. Bad Developer! No Release Notes! No Doughnut!

+
Is there a single JIRA issue somewhere that covers new inspections?
+

Not a bad idea. Let me think about it.

--Dave Griffith

0

Please sign in to leave a comment.