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?
请先登录再写评论。
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
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.
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
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
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
In article <9179072.1107985907189.JavaMail.itn@is.intellij.net>,
Dave Griffith <dave.griffith@cnn.com> wrote:
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
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>,
>
>
>>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
>
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.
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:
>>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
--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com
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
Thomas Singer (MoTJ) wrote:
>> I have the "should be final" check set on for local variables, off
>> for parameters.
>
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
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.
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.
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
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
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.
>
Try Ctrl-P
Alain
Alain Ravet 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.
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!"
Hello Stephen,
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!"
Rob
>
>> 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;
>> }
>
>
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.
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
In article <cuerj8$o1m$1@is.intellij.net>,
Martin Fuhrer <mf@fuhrer.com> wrote:
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
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
>
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
Perhaps it would be valuable to have a distinct "Color&Font" configuration
for reused local variables based on code analysis.
-tt
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.
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
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.
Hello Stephen,
>> little furry creatures from Alpha Centauri are real little furry
>> creatures from Alpha Centauri,
>>
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!"
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.
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.
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.