final final final

I just spent the first serious day of coding with EAP in a long while.

The most obvious thing I noticed was now idea thinks that just about every third line of my code needs a final token.

I understand the purpose but I've never seen common practice to use the final modifier so heavily in method code. IMO, it really pollutes the readability. Also, it would seem that within the scope of a method, the compiler ought to be able to figure out what references can be made final no?

So my question is: does it really make sense to have idea default to an warning for this inspection? Is there a good reason to encourage developers to use final so often?

31 comments
Comment actions Permalink

It's mostly a style / readability issue. Personally I think it clutters code;
I have the "Unnecessary final modifier" inspection enabled, myself. I don't
think either one should be on by default.

-Keith

I just spent the first serious day of coding with EAP in a long while.

The most obvious thing I noticed was now idea thinks that just about
every third line of my code needs a final token.

I understand the purpose but I've never seen common practice to use
the final modifier so heavily in method code. IMO, it really pollutes
the readability. Also, it would seem that within the scope of a
method, the compiler ought to be able to figure out what references
can be made final no?

So my question is: does it really make sense to have idea default to
an warning for this inspection? Is there a good reason to encourage
developers to use final so often?




0
Comment actions Permalink

Yes, I also thinnk both inspections should be off by default.
We adopted the policy of making every possible variable final. The intention was to clearly mark variables that get re-assigned after initialization.
IMHO it turned out bad: People forget the final modifier, polluting the code with inspection triggers. And, yeah, code gets a little bloated.
If I were to design a new Java language I'd propose a "var" modifier that I must add whenever a variable is going to be re-assigned. But that's pure fiction of course.

0
Comment actions Permalink

If I were to design a new Java language I'd propose a "var" modifier that
I must add whenever a variable is going to be re-assigned.


Yes, that would be a good idea.I do a lot of code reviewing and in this
process adding final whereever possible helps a lot to understand whats
going on. Most of the variables are indeed final, so turning this around to
declare mutable vars is probably better approach.

Ciao

...Jochen



0
Comment actions Permalink

Hello Jason,

JR> So my question is: does it really make sense to have idea default to
JR> an warning for this inspection? Is there a good reason to encourage
JR> developers to use final so often?

I don't think it's a good practice to use final everywhere. But this is just
my HO. IMHO the only place where you need final (except of course when you
need it to use variables inside anonymous classes, but this is a special
case to workaround anonymous classes design) is when you need to synchronize
on fields. Everything else is just cosmetic and not really worth it.

--
Dmitry Skavish


0
Comment actions Permalink

It's just style. I have the "should be final" check set on for local variables, off for parameters. Parameters should never be assigned to (and I have that inspection on), so marking them 'final' gives no information. I mark locals final mostly to keep me from doing anything stupid with them later. If I ever get the "reuse of local variable" inspection figured out, I'll probably turn the "final" check off for local variables as well.

--Dave Griffith

0
Comment actions Permalink

In article <9179072.1107985907189.JavaMail.itn@is.intellij.net>,
Dave Griffith <dave.griffith@cnn.com> wrote:

It's just style. I have the "should be final" check set on for local
variables, off for parameters. Parameters should never be assigned to (and I
have that inspection on), so marking them 'final' gives no information. I
mark locals final mostly to keep me from doing anything stupid with them
later. If I ever get the "reuse of local variable" inspection figured out,
I'll probably turn the "final" check off for local variables as well.

--Dave Griffith


I believe that the final keyword, when it comes to parameters, locals
and instance vars, have an effect on GC optimization in the way it gives
hints to the jvm, it does have performance effects as well (tried it
myself on that one). This is obviously different intended behavior that
those applied to method and class.

R

0
Comment actions Permalink

I think I read somewhere that it no longer makes a difference to
performance. I think it stopped making a difference in 1.4.

Norris Shelton
Sun Certified Java Programmer




Robert S. Sfeir wrote:

>In article <9179072.1107985907189.JavaMail.itn@is.intellij.net>,

Dave Griffith <dave.griffith@cnn.com> wrote:

>

>
>>It's just style. I have the "should be final" check set on for local
>>variables, off for parameters. Parameters should never be assigned to (and I
>>have that inspection on), so marking them 'final' gives no information. I
>>mark locals final mostly to keep me from doing anything stupid with them
>>later. If I ever get the "reuse of local variable" inspection figured out,
>>I'll probably turn the "final" check off for local variables as well.
>>
>>--Dave Griffith
>>
>>
>
>I believe that the final keyword, when it comes to parameters, locals
>and instance vars, have an effect on GC optimization in the way it gives
>hints to the jvm, it does have performance effects as well (tried it
>myself on that one). This is obviously different intended behavior that
>those applied to method and class.
>
>R

>

0
Comment actions Permalink

I believe that the final keyword, when it comes to parameters, locals
and instance vars, have an effect on GC optimization in the way it
gives hints to the jvm, it does have performance effects as well
(tried it myself on that one). This is obviously different intended
behavior that those applied to method and class.


I don't believe this. The JVM knows a great deal about your code as soon
as it loads it, and it doesn't need to be told which variables are reused
and which ones aren't. Maybe on an old or non-Sun JVM what you say is true,
but I don't believe it for modern (1.4, 5.0) VM's.


0
Comment actions Permalink

The final keyword for parameters and locals is used by the compiler
only. While different bytecode may be produced by the compiler, the jvm
itself doesn't know anything about a parameter/local being declared final.

Robert S. Sfeir wrote:

In article <9179072.1107985907189.JavaMail.itn@is.intellij.net>,
Dave Griffith <dave.griffith@cnn.com> wrote:

>>It's just style. I have the "should be final" check set on for local
>>variables, off for parameters. Parameters should never be assigned to (and I
>>have that inspection on), so marking them 'final' gives no information. I
>>mark locals final mostly to keep me from doing anything stupid with them
>>later. If I ever get the "reuse of local variable" inspection figured out,
>>I'll probably turn the "final" check off for local variables as well.
>>
>>--Dave Griffith


I believe that the final keyword, when it comes to parameters, locals
and instance vars, have an effect on GC optimization in the way it gives
hints to the jvm, it does have performance effects as well (tried it
myself on that one). This is obviously different intended behavior that
those applied to method and class.

R


--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

0
Comment actions Permalink

I have the "should be final" check set on for local variables, off for parameters.


Same for me. The final makes it easier for me to see local variable
declarations. Since we are using relatively long class names, we avoid final
for parameters (where possible), because otherwise they would be too much
out of screen.

Tom

0
Comment actions Permalink

Thomas Singer (MoTJ) wrote:

>> I have the "should be final" check set on for local variables, off
>> for parameters.
>

Same for me. The final makes it easier for me to see local variable
declarations.



While we're sharing all conventions:

I prefix all my parameters with "i_" (input), "o_" (output) and "io_"
(mixed)
public int removeOddWords (int i_size, List io_data) {...
..
io_data.remove (..);
..
return nofModifs;
}


I prefix instances variables with "__" (private), nothing (public), ..
=> no collision, no need for "this.",

public class Foo {
String __name ;
public Foo (String i_name) {
__name = i_name;
}
}


, and I use "final" only
- when it's mandatory (accessed by an anonymous class)
- to show that a class/object is immutable
=> no need for getters

public class Pair {
final int x,y ;
public Pair (int i_x, int i_y) {
x = i_x;
y = i_y;
}
}

Alain

0
Comment actions Permalink

Which is really silly considering the fact that any such contracts (that are important) are in the Javadoc tag. Parameter names are not in the class file as we all know, so that clutter is useless and ugly.

0
Comment actions Permalink

I know a lot of people do these kind of prefixes, but i dont prefer it. (also against the java naming convention)

Regarding the 'final' keyword i used to go crazy with it before, but now i dont really bother with it.

0
Comment actions Permalink

did some bytecode watching, because we had a discussion regarding the final keyword here

conclusion is that code that differs in declaring method parameters as final or not results in the same bytecode (jdk 1.4)

local variables declared final or not result in different bytecode

can't say what effects the differences might have

0
Comment actions Permalink

local variables declared final or not result in different bytecode


There's a possible gain in performance, since there's no need to read
the local variable before using it - it's impossible that it's value
could have changed. But that's purely a compile-time optimization. The
fact that the variable has been declared final is not reflected in the
generated class file.

--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

0
Comment actions Permalink

Patrik Andersson wrote:

>Which is really silly
>
Thanks.

>considering the fact that any such contracts (that are important) are in the Javadoc tag.
>

When I see one line of - my - code, that uses a mix of parameters,
local variables, and instance variables, I don't need to look elsewhere
- especially not in the javadoc, that I barely use - to know their
scope, and meaning, and purpose. It makes reading and understanding
code, and tracking bugs, a lot easier. Like using ALL UPPERCASE for
constants. A simple convention, that holds a lot of info in a tiny space.

Parameter names are not in the class file as we all know, so that clutter is useless and ugly.

>
Try Ctrl-P



Alain

0
Comment actions Permalink

Alain Ravet wrote:

Thomas Singer (MoTJ) wrote:

>>> I have the "should be final" check set on for local variables, off
>>> for parameters.
>>
>>
>> Same for me. The final makes it easier for me to see local variable
>> declarations.



While we're sharing all conventions:

I prefix all my parameters with "i_" (input), "o_" (output) and "io_"
(mixed)
public int removeOddWords (int i_size, List io_data) {...
..
io_data.remove (..);
..
return nofModifs;
}


Doesn't that get in the way of code completion if all variables start
with one of three prefixes? You'd have to think about the input/output
type of the variable everytime you try to type it or use Ctrl-Space.
Have you thought of maybe making them suffixes instead of prefixes?

--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Hello Stephen,



If I were to design a new Java language I'd propose a "var" modifier
that I must add whenever a variable is going to be re-assigned. But
that's pure fiction of course.

In a parallel universe, where men a real men, women are real women, and
little furry creatures from Alpha Centauri are real little furry creatures
from
Alpha Centauri, they code in OCaml, Haskell and other fancy, safe and beautiful

languages, and they do not have any mutable variables at all.

<info-leak>
That universe will probably possibly be bridged with our universe perhaps
when
a future version of ReSharper is out, if our interns are bright enough
(which they are) and industrious enough (hey guys, I am sure you read this!).

</info-leak>

And yes, count me in on that 'var' modifier. Final must go! Everyone is final
in my
code anyway!

Cheers,
Dmitry

--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"


0
Comment actions Permalink

Rob

Alain Ravet wrote:

>
>> I prefix all my parameters with "i_" (input), "o_" (output) and "io_"
>> (mixed)
>> public int removeOddWords (int i_size, List io_data) {...
>> ..
>> io_data.remove (..);
>> ..
>> return nofModifs;
>> }
>
>

Doesn't that get in the way of code completion if all variables start
with one of three prefixes
You'd have to think about the input/output type of the variable
everytime you try to type it or use Ctrl-Space.




1/ 95% of the params are input only - "i_param"-, so I just need to type
"i_" and press Ctrl-Space,
2/ I try to keep my methods short - 1 screen high -, so I can easily
peek at the method signature, should I need it.

Have you thought of maybe making them suffixes instead of prefixes?


It wouldn't work, as we all naturally stop reading a word, once our
brain has recognized it.
When I read

i_firstName

my brains sees 2 pieces of info
1/ it's an input parameter, coming from the method caller, for me
to use/process in this method
2/ it's about a first name.

It's really a practive you have to, well, practice. Once you're used to
it, you have no problem reading and understanding the data scope and
flow in code like:

foo (String i_name) {
String name = i_name.trim();
...
__name = name ;
}

i_name is the input param
name is the local var
__name is the private instance method.

The only collision occurs with public instance methods (no "_"), but I
use them rarely, and only in cases like
public class Pair {
public final int x,y;
public Pair (int i_x, int i_y) {
x = i_x;
y = i_y;
}
}

Alain

0
Comment actions Permalink

In article <cuerj8$o1m$1@is.intellij.net>,
Martin Fuhrer <mf@fuhrer.com> wrote:

The final keyword for parameters and locals is used by the compiler
only. While different bytecode may be produced by the compiler, the jvm
itself doesn't know anything about a parameter/local being declared final.

Robert S. Sfeir wrote:

In article <9179072.1107985907189.JavaMail.itn@is.intellij.net>,
Dave Griffith <dave.griffith@cnn.com> wrote:

>>It's just style. I have the "should be final" check set on for local
>>variables, off for parameters. Parameters should never be assigned to (and
>>I
>>have that inspection on), so marking them 'final' gives no information. I
>>mark locals final mostly to keep me from doing anything stupid with them
>>later. If I ever get the "reuse of local variable" inspection figured
>>out,
>>I'll probably turn the "final" check off for local variables as well.
>>
>>--Dave Griffith


I believe that the final keyword, when it comes to parameters, locals
and instance vars, have an effect on GC optimization in the way it gives
hints to the jvm, it does have performance effects as well (tried it
myself on that one). This is obviously different intended behavior that
those applied to method and class.

R


Geez, I was just throwing it out there as something I had come across at
some point, didn't mean to cause havoc... gosh :)

R

0
Comment actions Permalink

JDK 1.4 made this basically obsolete.

Norris Shelton
Sun Certified Java Programmer




Tim Easy wrote:

>did some bytecode watching, because we had a discussion regarding the final keyword here
>
>conclusion is that code that differs in declaring method parameters as final or not results in the same bytecode (jdk 1.4)
>
>local variables declared final or not result in different bytecode
>
>can't say what effects the differences might have

>

0
Comment actions Permalink

Thomas Singer (MoTJ) wrote:

While we're sharing all conventions:

I prefix all my parameters with "i_" (input), "o_" (output) and "io_"
(mixed)
I prefix instances variables with "__" (private), nothing (public), ..
=> no collision, no need for "this.",


I don't want to argue with anyone about code style better or worse, I only
want to share something that I think about IDEA and naming conventions.

I think IDEA's semantic code highlighting removes the need for conventions
like this. In my code, I can look at a variable usage and see whether it's
a field or a local variable (based on whether it's bold and colored or not).

When I see a local variable, I don't care whether it's an input paramter,
output parameter, or local variable; the variable's name describes its role
in the method, without some kind of prefix.

Sometimes I have to use "this.", but I think it's a small price to pay for
missing lots of ugly _'s. Usually I avoid this, though, by naming local variables
different names than already existing fields.

-Keith


0
Comment actions Permalink

It's just style. I have the "should be final" check set on for local
variables, off for parameters. Parameters should never be assigned to
(and I have that inspection on), so marking them 'final' gives no
information. I mark locals final mostly to keep me from doing
anything stupid with them later. If I ever get the "reuse of local
variable" inspection figured out, I'll probably turn the "final" check
off for local variables as well.


Perhaps it would be valuable to have a distinct "Color&Font" configuration
for reused local variables based on code analysis.

-tt


0
Comment actions Permalink

little furry creatures from Alpha Centauri are real little furry creatures from Alpha Centauri,


Dmitry, I had to learn recently that quoting the hitchhiker's guide is a sure sign to show you're age. Inbelievable, but there indeed are youngsters wo have never heard of it.

0
Comment actions Permalink

Stephen Kelvin wrote:

>
>Dmitry, I had to learn recently that quoting the hitchhiker's guide is a sure sign to show you're age. Inbelievable, but there indeed are youngsters wo have never heard of it.

>

There is worse:
A recent poll showed that youngsters don't recognize the sound of a
needle scratching the surface of a vinyl disk => it can't be used in
advertisement anymore, as it doesn't ring their bells.

Alain

0
Comment actions Permalink

A recent poll showed that youngsters don't recognize
the sound of a
needle scratching the surface of a vinyl disk => it
can't be used in
advertisement anymore, as it doesn't ring their
bells.


There goes one of my favorite "nostalgia triggers"... The scratch of a needle in vinyl used to be perfect to to represent "something from the past", be it in music (even modern music, like Incubus' "Anti Gravity") or in advertising.

Oh well, the world sure changes... till the yellow Vogon trucks arrive.

0
Comment actions Permalink

Hello Stephen,

>> little furry creatures from Alpha Centauri are real little furry
>> creatures from Alpha Centauri,
>>

Dmitry, I had to learn recently that quoting the hitchhiker's guide is
a sure sign to show you're age. Inbelievable, but there indeed are
youngsters wo have never heard of it.


When has the world changed so that at 25 you are out and done with?
Stop the earth, I am getting off.

Dmitry

P.S. Valentin, you are right - we cannot market F# plugin. They are only
interested in their nostalgia....

---
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"


0
Comment actions Permalink

IDEA provides all that context information at the press of CtrlQ. CtrlP wont give you jack without sources, which is what I said. Parameter information is not in the class file.

0
Comment actions Permalink

Patrik Andersson wrote:

>IDEA provides all that context information at the press of CtrlQ. CtrlP wont give you jack without sources, which is what I said. Parameter information is not in the class file.

>

It's MY coding convention, that I use in MY code, and I have the source
of MY code.


A.

0
Comment actions Permalink

Java isn't JustText though. There's no need to litter it with ugly pre/suffixes and other abominations. There's always a nested context of syntax, semantics and the current code domain. It's a path:

/StringReference/MethodContext/name=firstName/className=Person/package=domain.model

Given that, what does i_ add that isn't immidiately visible from reading the method source? i_ is redundant information. Redundant information suffers from its susceptability to getting out-of-sync with the code it appears in. Consider the following:

void foo(List i_bar) {
i_bar.remove(0);
}

Trivialised example, I know. The actual text you type should contain as little dirt as possible. Small and clean. That way you can easily use it to express the domain without the expression method getting in the way. It's not(negation) like(comparison) I(subject) point(verb) out(preposition? see how errors creep in) to(preposition) you(subject) that(etc...) 'point' is a verb in the context of this sentence.

0

Please sign in to leave a comment.