Inspection - Reuse of local variable

How hard would it be to add an option to ignore variables with temp in
their name?

11 comments

It wouldn't be that hard. Do you reuse your temp variables a lot?

Bas

Norris Shelton wrote:

How hard would it be to add an option to ignore variables with temp in
their name?

0

In principle I like this inspection a lot.
However it highlights a principle problem with inspections.
You cannot write code that never reuses local variables (at least not without
a pathological coding style).
So if you enable this inspection you either have to suppress a lot of warnings,
or you have to check in code that isn't green. Both are Bad Things.
The "temp" naming convention is a feasible workaround.
I would like it much better, though, if there were an inspection level "info":
I really want to have variables which are reused highlighted, it just should
not be a warning.

Bas Leijdekkers wrote:

It wouldn't be that hard. Do you reuse your temp variables a lot?

Bas

Norris Shelton wrote:

>> How hard would it be to add an option to ignore variables with temp in
>> their name?

0

Stephen Kelvin wrote:

I really want to have variables which are reused highlighted, it just
should
not be a warning.

In the latest EAP at least, you can apply specific color and formatting
to reassigned variables and parameters. Not sure how long that's been
in there.

N.

0

What's the use case? Note that there is already an option on that inspection to ignore it for variables immediately returned or thrown, for debugging purposes. For what other patterns does reusing a local make sense?

--Dave Griffith

0

In some cases. I may have to perform the same operation on several
different values - say convert an Integer to a String and compare it's
value.

Bas Leijdekkers wrote:

It wouldn't be that hard. Do you reuse your temp variables a lot?

>

Bas

>

Norris Shelton wrote:

>> How hard would it be to add an option to ignore variables with temp
>> in their name?

0

In one case I am processing a list of record types for customers. I
loop through DB results and throw each object into my temporary variable
and interrogate the object to ensure that I should allow this record
type for this type of operation.

Dave Griffith wrote:

What's the use case? Note that there is already an option on that inspection to ignore it for variables immediately returned or thrown, for debugging purposes. For what other patterns does reusing a local make sense?

>

--Dave Griffith

0

Reasonable, but why don't you define the variable inside the loop?

Bas

Norris Shelton wrote:

In one case I am processing a list of record types for customers. I
loop through DB results and throw each object into my temporary variable
and interrogate the object to ensure that I should allow this record
type for this type of operation.

Dave Griffith wrote:

>> What's the use case? Note that there is already an option on that inspection to ignore it for variables immediately returned or thrown, for debugging purposes. For what other patterns does reusing a local make sense?
>>
>> --Dave Griffith
>>

0

Oh my, my mouth (fingers) were faster than my brain.
I thought the inspection would trigger if you sum up values in a loop.
Of course it is much more clever.
So allow me to correct myself: There shouldn't be an option to suppress
it (other than the regular suppress annotation).
It always makes sense to "split" the local variable, as the quickfix is called.
(I only hope there isn't some corner case where reuse might be needed -
don't want to be wrong again.)

Luckily Superman (or was it Batman ;) ) is slightly wrong, too:
The options named are present in the "Redundant local variable" inspection
not in this reuse inspection.

BTW it would be very nice if live-template-like editing would be started
automatically, so that I can rename the variable easily after quickfixing.
(Currently you could do that by creating and applying a live template on
the fly. But maybe it makes sense to wait for the promised inline refactoring
of Demetra.)

Dave Griffith wrote:

What's the use case? Note that there is already an option on that inspection to ignore it for variables immediately returned or thrown, for debugging purposes. For what other patterns does reusing a local make sense?

--Dave Griffith

0

I was always taught to declare it outside the loop, then re-use it
within the loop. Isn't that correct?

Bas Leijdekkers wrote:

Reasonable, but why don't you define the variable inside the loop?

>

Bas

>

Norris Shelton wrote:

>> In one case I am processing a list of record types for customers. I
>> loop through DB results and throw each object into my temporary
>> variable and interrogate the object to ensure that I should allow
>> this record type for this type of operation.
>>
>> Dave Griffith wrote:
>>> What's the use case? Note that there is already an option on that
>>> inspection to ignore it for variables immediately returned or
>>> thrown, for debugging purposes. For what other patterns does
>>> reusing a local make sense?
>>>
>>> --Dave Griffith
>>>

0

Norris Shelton wrote:

I was always taught to declare it outside the loop, then re-use it
within the loop. Isn't that correct?


If I am not completely mistaken (which sometimes happens) it makes absolutely
no difference in Java: The byte code for a method contains the total number
of local variables. This number determines how much space is reserved on the
stack frame regardless of where the variable is actually declared.

0

It doesn't matter if you declare the variable inside the loop or outside
the loop and only use it inside, the byte code generated by javac is the
same. You might want to try the "Scope of variable is too broad"
inspection, which also highlights such cases.

Bas


Norris Shelton wrote:

I was always taught to declare it outside the loop, then re-use it
within the loop. Isn't that correct?

Bas Leijdekkers wrote:

>> Reasonable, but why don't you define the variable inside the loop?
>>
>> Bas
>>
>> Norris Shelton wrote:
>>> In one case I am processing a list of record types for customers. I
>>> loop through DB results and throw each object into my temporary
>>> variable and interrogate the object to ensure that I should allow
>>> this record type for this type of operation.
>>>
>>> Dave Griffith wrote:
>>>> What's the use case? Note that there is already an option on that
>>>> inspection to ignore it for variables immediately returned or
>>>> thrown, for debugging purposes. For what other patterns does
>>>> reusing a local make sense?
>>>>
>>>> --Dave Griffith
>>>>

0

Please sign in to leave a comment.