Should all the input parameters to a method be final?
Many good-programming-practice-related books say that the parameter to a method should be declared final.
For ex, like this:
publicvoid foo(finalint bar){
}
The argument those books defend is that, what if you change the variable somewhere in the middle and you want the original value that passed later on when you are coding the same method... But that doesn't happen all the time. There may be situations where I want to alter my input value, in a method like this:
publicstaticboolean isNullOrEmpty(String string,boolean shouldTrim){
if (null == string){
returntrue;
}
if (shouldTrim){
// I am resetting my original input value here.
string = string.trim();
}
if (0 == string.length()){
returntrue;
}
returnfalse;
}
And I think the code below is recommended with respect to my question versus the previous one.
publicstaticboolean isNullOrEmpty(final String originalValue,finalboolean shouldTrim){
String string = originalValue;
if (null == string){
returntrue;
}
if (true == shouldTrim){
string = originalValue.trim();
}
if (0 == string.length()){
returntrue;
}
returnfalse;
}
But this alone doesn't seem to satisfy me, Is there anything else that I am missing? your thoughts?
Thanks,
Srikanth
[3089 byte] By [
sri1025a] at [2007-11-26 12:41:57]
# 1
Personally I treat them as you should treat any other variable:Make every variable final unless it needs to be assigned more than once.
# 2
Personally,It's not a good choise for all the input parameters!
# 3
> Personally I treat them as you should treat any other
> variable:
>
> Make every variable final unless it needs to be
> assigned more than once.
I like that in theory, and we practice that at my current place. However, I find that the code ends up being very cluttered and verbose. I understand and agree with the motivation for it, but I don't like what it does to my code. Almost makes me wish variables were final by default and required a var modifier if you want to change their value.
# 4
> > Make every variable final unless it needs to be
> > assigned more than once.
>
> I like that in theory, and we practice that at my
> current place. However, I find that the code ends up
> being very cluttered and verbose. I understand and
> agree with the motivation for it, but I don't like
> what it does to my code.
I feel exactly the same. It's quite a dilemma :-)
> Almost makes me wish
> variables were final by default and required a
> var modifier if you want to change their value.
I am proverbially crying with happiness to hear someone else state this.
Lokoa at 2007-7-7 16:15:52 >
# 5
> > Make every variable final unless it needs to be
> > assigned more than once.
>
> I like that in theory, and we practice that at my
> current place. However, I find that the code ends up
> being very cluttered and verbose. I understand and
> agree with the motivation for it, but I don't like
> what it does to my code.
This is how I feel about final locals too. It's another keyword to parse in my head when I read code. The extra clutter isn't that much but it's there.
On the other hand I don't ever recall having had a bug due to accidental modification of a variable. Nor do I recall ever thinking "I wonder if this variable is modified later; I wish this code used 'final' so I knew." The functioning of a dozen lines of code has a few dozen little details; whether a parameter is reassigned is one of the less interesting details, and requires no extra fanfare to advertise in advance.
So I have never seen a practical (as opposed to a theoretical) benefit to final, and I see a small disadvantage. So I don't use it unless instructed by The Pointy-Haired One.
(Non-local finals, as constants, are occasionally a different issue.)
# 6
That's the flip-side to this: Yeah, it's nice in theory, but if you're methods are resaonbly small and simple, the occurence of errors--inadvertently modifying a variable you weren't supposed to--is quite low. I like the idea of making a distinction between variables that can be modified and those that won't, but I'm not convinced the cost of the clutter and verbosity is justified for the benefit realized.
# 7
>
> This is how I feel about final locals too. It's
> another keyword to parse in my head when I read code.
> The extra clutter isn't that much but it's there.
>
> On the other hand I don't ever recall having had a
> bug due to accidental modification of a variable. Nor
> do I recall ever thinking "I wonder if this variable
> is modified later; I wish this code used 'final' so I
> knew." The functioning of a dozen lines of code has a
> few dozen little details; whether a parameter is
> reassigned is one of the less interesting details,
> and requires no extra fanfare to advertise in
> advance.
>
> So I have never seen a practical (as opposed to a
> theoretical) benefit to final, and I see a small
> disadvantage. So I don't use it unless instructed by
> The Pointy-Haired One.
>
I agree.
If one could actually create real constants with the addition of a keyword like C++ does then I would probably use them all the time. But as it is no.
# 8
Sorry to drift away from my original post, but I think I had posted a reply to this topic and I can't see it now. Can anyone tell me the reason? Bug in forum software or deleted by someone?
# 9
I'd also like the reverse logic for marking variable variables as variable ;)
I'm not sure about when exactly the final keyword was introduced, but I guess introducing final, and not the inverse, has to do with backwards-compatibility, as always. As stated in the JLS, Ed. 1, adding final may "break compatibility with pre-existing binaries". So I'd guess, final was introduced quite then.
# 10
> Almost makes me wish variables were final by default > and required a var modifier if you want to change > their value.Yes, completely agree with you.
# 11
Btw., ant users will know what it means to only have "final variables".
# 12
I always liked the const modifier in C++. Java's final isn't the same thing at all.Allowing side effects by changing parameters is something I despise. I liked building it into C++ contracts: "I promise my method won't alter what you pass to me."%
# 13
> Many good-programming-practice-related books say that
> the parameter to a method should be declared final.
>
> For ex, like this:
> > public void foo(final int bar) {
> }
>
Many good books don't recommend that.
> The argument those books defend is that, what if you
> change the variable somewhere in the middle and you
> want the original value that passed later on when you
> are coding the same method...
Not the winning argument, IMO.
> But that doesn't happen all the time.
I think the issue is about side effects. Clients passing in values shouldn't be surprised by you changing what they've given you.
> There may be situations where I want to
> alter my input value, in a method like this:
> > public static boolean isNullOrEmpty(String string,
> boolean shouldTrim) {
> if (null == string) {
> return true;
> }
>
> if (shouldTrim) {
> // I am resetting my original input value here.
> string = string.trim();
> }
>
> if (0 == string.length()) {
> return true;
> }
>
> return false;
> }
>
You could have done the same thing with a local variable and not disturbed the input. Just a poor choice.
> And I think the code below is recommended with
> respect to my question versus the previous one.
>
> > public static boolean isNullOrEmpty(final String
> originalValue, final boolean shouldTrim) {
> String string = originalValue;
>
> if (null == string) {
> return true;
> }
>
> if (true == shouldTrim) {
> string = originalValue.trim();
> }
>
> if (0 == string.length()) {
> return true;
> }
>
> return false;
> }
>
That's better.
See above - it's about side effects and contracts, IMO.
%
