"Mutable" local variable/parameter

Mutating variables? :)

-

Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"

When I saw this feature in the build announcement I assumed it meant
that local variables and parameters not declared final would have the
configured color. But the actual behavior is different: It appears to
be that a variable is considered "mutable" if its value is set more
than once within the method.

I presume that's the intended behavior. It's certainly useful. I
wonder if some description other than "mutable" (which I don't think
I'll be alone in assuming just means the opposite of "final") might be
better. I admit, though, that I can't think of anything better.

Maxim Shafirov wrote:

Mutating variables? :)

Mutated?

Modified?

Re-assigned?

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

Maxim Shafirov wrote:

Mutating variables? :)

"Mutated variables" would probably be more precise, but sounds
a bit like the title of a bad horror movie ;)

I'd prefer "Re-assigned variables", "Modified variables",
"Write-accessed Variables".

Sascha

Hello Sascha,

Maxim Shafirov wrote:

>> Mutating variables? :)

:)

>>

"Mutated variables" would probably be more precise, but sounds a bit
like the title of a bad horror movie ;)

I'd prefer "Re-assigned variables", "Modified variables",
"Write-accessed Variables".

I'd vote for the first, "Re-assigned variables". This puts the focus on multiple
assignments.

tt

Hello Sascha,

>> Maxim Shafirov wrote:
>>
>>> Mutating variables? :)
>>>

:)

>> "Mutated variables" would probably be more precise, but sounds a bit
>> like the title of a bad horror movie ;)
>>
>> I'd prefer "Re-assigned variables", "Modified variables",
>> "Write-accessed Variables".
>>

I'd vote for the first, "Re-assigned variables". This puts the focus
on multiple assignments.

I like re-assigned best too. "Mutated variable" implies to me that you called
a mutating method on the variable's value.

Interestingly enough, it seems to actually be doing some dataflow analysis, rather than just counting assignments.
If a variable is assigned twice, but those assignments couldn't both occur (different branches of if statement at same level as the variable declaration, for instance), it doesn't mark them.

Very cool, but if you're going to be doing dataflow analyses may I suggests doing them inspections instead of (or in addition to) code style settings.

--Dave Griffith

Yes, I agree. It definitely seems smarter than just counting
assignments. I like the use of coloring for this (can't call it syntax
coloring in this case, can we?). I think it's more appropriate than an
inspection. It's purely informational--there's nothing really /wrong/
here. Well, some might disagree, at least in the case of parameters.

And "re-assigned variables" is a good choice, I think.

Dave Griffith wrote:

Interestingly enough, it seems to actually be doing some dataflow analysis, rather than just counting assignments.
If a variable is assigned twice, but those assignments couldn't both occur (different branches of if statement at same level as the variable declaration, for instance), it doesn't mark them.

Very cool, but if you're going to be doing dataflow analyses may I suggests doing them inspections instead of (or in addition to) code style settings.

--Dave Griffith

Hmm, I see your point. I would only say that reassigned variables were wrong in the case where they could be split into separate local variables with smaller scopes or lifetimes. I've got a long-outstanding request for such an inspection.

The current algorithm seems to just be the "local variable can be final" inspection, used as input to the syntax coloring engine. Clever.

Agreed on naming. "Reassigned" is the way to go.

--Dave Griffith

Reassigned is much better (it passed the ultimate test - my wife guessed
what it does, by only telling her the name :)

Mutating variables? :)

Mutants!

Yes, the setting means exactly "that variable/parameter cannot be declared
final because it has been assigned to at least twice in the control flow
path". Parameters naturally considered to be assigned in the point of
declaration.
Renamed to 'reassigned variable' in the next build.

--
regards,
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:10995197.1112210678983.JavaMail.itn@is.intellij.net...
>

Interestingly enough, it seems to actually be doing some dataflow
analysis, rather than just counting assignments.
If a variable is assigned twice, but those assignments couldn't both occur
(different branches of if statement at same level as the variable
declaration, for instance), it doesn't mark them.

>

Very cool, but if you're going to be doing dataflow analyses may I
suggests doing them inspections instead of (or in addition to) code style
settings.

>

--Dave Griffith

>