CheckStyle Rule : Making final to the local variables

[hemant Budhewar BamniBk]

Check Style Rule : FinalLocalVariable--

Checks that local variables that never have their values changed are declared final. The check can be configured to also check that unchanged parameters are declared final.

Can anybody suggest me more disadvantages of using this check style rule through out the code of big project?

However I found one major disadvantage by enabling this rule in Eclipse, i.e. it hampers readability of the software and disallowing engineers (team members) to understand new code more quickly and thoroughly.

[Campbell Ritchie]

How does labelling local variables final make code difficult to read?

[Ernest Friedman-Hill]

I would argue that the opposite is true: final variables make code considerably easier to read. If you know that a variable will never be changed, then you can make a lot of assumptions about it while you read.

[Anirudh Vyas]

exactly and plus when you are trying to refactor your code to make it more OO so as to speak, this will come in handy! (I have written extensively on this here : defensive programming ... so feel free to check it out!

[David Newton]

How does making a variable "final" make code more OO?

[Mike Simmons]

Um, no one said it did. Anirudh did say that if you're refactoring your code to be more OO, final variables make that easier. Not the same thing.

[David Newton]

...

How does making local variables final make it easier to make code more OO?

[hemant Budhewar BamniBk]

Campbell Ritchie wrote:How does labelling local variables final make code difficult to read?

I have come across a file having more than 2000 lines. Each constructor, static block and methods of this file contains many local variables. So with this rule I have labeled all the local variables which have not changed as final.

By doing this my whole file contains final , final, final ... everywhere.

In my project there are many such files which are having same situation.

Can anybody read such code quickly, so that development becomes fast.

I don't think so.

[Ulf Dittmer]

I have come across a file having more than 2000 lines.

Ouch! I'd say once a class goes beyond a couple hundred lines of code or so, it is time to start refactoring.

[hemant Budhewar BamniBk]

Ernest Friedman-Hill wrote:I would argue that the opposite is true: final variables make code considerably easier to read. If you know that a variable will never be changed, then you can make a lot of assumptions about it while you read.

If it is so then, why this Check style rule is not applied in sun's standard classes, or any other software code?

My main aim is to know how much this rule is beneficial for code quality.

Wanted to know this because I have not seen any standard packages like org, net , java following this rule.

In all the standard packages, we don't find such rule applied to make all the loacl variables final...

[Mike Simmons]

David Newton wrote:How does making local variables final make it easier to make code more OO?

I think using final makes it easier to understand what code does (and what it doesn't do). If I know a variable is final, I don't have to think about it as much. Which in turn makes it easier to perform any refactoring. I'm not sure there's anything intrinsically OO about it.

On the other hand...

Campbell Ritchie wrote:How does labelling local variables final make code difficult to read?

I do find it's just one more thing to read, which is kind of annoying. In method declarations, particularly, it's a little tedious to put final in front of every parameter. In fact I'd prefer it if variables were final by default, and we had another keyword (like, say, var) to signal when they're not final. Mutability should be the exception, immutability the norm. But that's unlikely to ever happen in Java - oh well. I still think it's better to put final in front of any variable you can - I just find the style to be less elegant than it could be.

[hemant Budhewar BamniBk]

Ulf Dittmer wrote:

I have come across a file having more than 2000 lines.

Ouch! I'd say once a class goes beyond a couple hundred lines of code or so, it is time to start refactoring.

What about if the development is already done and if it has more regression in refactoring the complex code?

This is the case which I am facing

[Mike Simmons]

hemant Budhewar BamniBk wrote:Can anybody read such code quickly, so that development becomes fast.

I don't think so.

I think it's mostly a matter of what you're used to. If it's a standard part of your company's style, you get used to it, expect it, and just skip over it. If it's something unusual to you, you spend time wondering "why is this variable final?" and it slows you down.

hemant Budhewar BamniBk wrote:If it is so then, why this Check style rule is not applied in sun's standard classes, or any other software code?

Well, Sun's style was developed long ago, whereas a preference for immutability is something that's becoming popular more recently. I wouldn't expect Sun to go back an insert final in a bunch of old code. It is a good question why we don't see this style used more for new projects and organizations.

hemant Budhewar BamniBk wrote:My main aim is to know how much this rule is beneficial for code quality.

In my opinion, it's beneficial, but only marginally. So there's not a big compulsion to convince others to do it. Further, it's most beneficial if you have long methods - and I am pretty aggressive about making my methods as short as possible. For people who keep their methods short, it doesn't matter very much whether the local variables are final - the shortness makes it easy to see what happens to the variable. And I think short methods are much more important than final local variables.

On the other hand, I do aggressively apply final to any field that I can. And there are many others out there who do the same. That's much more beneficial, because fields generally stick around much longer than local variables. So simplifying their behavior has a bigger impact on understandability. And of course it's very helpful for multithreaded code. That's not what this thread is about, of course, but I thought it worth clarifying.

[hemant Budhewar BamniBk]

Mike Simmons wrote:

If it's something unusual to you, you spend time wondering "why is this variable final?" and it slows you down.

If whole project code contains all final LOCAL variables, then it is obvious to get question ("why is this variable final?")for any new devloper who works on such code.

This is because, generally when we label final to the local variable, devloper thinks it for "Local classes purpose" rather thinkin for minor gain i.e "accidental modification of the variable in big method".

And if he is not finding any local classes which are using such final loacl variables, then obliviously it slows down him.

hemant Budhewar BamniBk wrote:
Well, Sun's style was developed long ago, whereas a preference for immutability is something that's becoming popular more recently. I wouldn't expect Sun to go back an insert final in a bunch of old code. It is a good question why we don't see this style used more for new projects and organizations.

Is anybody having idea about this good question

hemant Budhewar BamniBk wrote:
In my opinion, it's beneficial, but only marginally. So there's not a big compulsion to convince others to do it. Further, it's most beneficial if you have long methods - and I am pretty aggressive about making my methods as short as possible. For people who keep their methods short, it doesn't matter very much whether the local variables are final - the shortness makes it easy to see what happens to the variable. And I think short methods are much more important than final local variables.

Thanks Mike for your opinion

hemant Budhewar BamniBk wrote:
On the other hand, I do aggressively apply final to any field that I can. And there are many others out there who do the same. That's much more beneficial, because fields generally stick around much longer than local variables. So simplifying their behavior has a bigger impact on understandability. And of course it's very helpful for multithreaded code. That's not what this thread is about, of course, but I thought it worth clarifying.

I agree about field, if we label a filed as final then we don't have to bother about its modification and hence also we don't need to apply synchronization on its use. So making final to field improves performance.

This CheckStyle rule applies to short methods also like setters which raises question why this final to method parameter, as no local class exist which are using the same final variable and method is short

[David Newton]

Ulf Dittmer wrote:

I have come across a file having more than 2000 lines.

Ouch! I'd say once a class goes beyond a couple hundred lines of code or so, it is time to start refactoring.

Oh, have I got a Java class for you. The *source* file was 1M and was around 33k lines. No, really. Eclipse almost herniated a disk (see what I did there?) opening it. It was a giant file containing a giant if/else construct for a giant, horrible "rules engine", driven by the afore-mentioned giant if/else construct.

Seriously.

I also dealt with a 3k line servlet doPost() method once. In real life on a real site.

Also a JSP-based site (Javadocs for our classes? No, they're all in JSP files, thanks.) that used a home-grown "custom tag" system that re-parsed the template file every time the page loaded.

Okay, I'm done now--just venting.

[Jeanne Boyarsky]

hemant Budhewar BamniBk wrote:What about if the development is already done and if it has more regression in refactoring the complex code?

If development is completely done and you aren't getting enhancement requests, why are you sitting there adding the final keyword? Seriously, I refactor code I am going to touch. Or code with a bigger problem that we have agreed to refactor after release. I don't just go randomly changing code.

As for final, I use it in new code inconsistently. I mainly use it when I want to make it clear that a local variable shouldn't change. Not when it just happens to not change. I never use final in method parameters because I have another static analysis rule that flags when a method parameter gets set. That rule is higher severity than the one to use the final keyword. And of course I do use final for class level constants.

I also think that new methods should be written smaller so there aren't so many variables present. Making the benefit of this less important.

[Campbell Ritchie]

At risk of being transferred to Meaningless Drivel (or worse)

How did you fit that big if-else in? You can't get a method bigger than 64K.

I once had something similar, but (thank goodness) smaller when trying parsing by hand. Lots of nasty switch blocks. I tried my hardest to transfer control from each arm to a different method wherever possible, so as to keep the methods to a more manageable size.

Have you ever seen the sort of methods you get out of JFlex to implement text scanning rules?

[hemant Budhewar BamniBk]

Jeanne Boyarsky wrote:

hemant Budhewar BamniBk wrote:What about if the development is already done and if it has more regression in refactoring the complex code?

If development is completely done and you aren't getting enhancement requests, why are you sitting there adding the final keyword? Seriously, I refactor code I am going to touch. Or code with a bigger problem that we have agreed to refactor after release. I don't just go randomly changing code.

As for final, I use it in new code inconsistently. I mainly use it when I want to make it clear that a local variable shouldn't change. Not when it just happens to not change. I never use final in method parameters because I have another static analysis rule that flags when a method parameter gets set. That rule is higher severity than the one to use the final keyword. And of course I do use final for class level constants.

I also think that new methods should be written smaller so there aren't so many variables present. Making the benefit of this less important.

oh, actually its old code, enhancement is also going and bug fixing is also going on.

[hemant Budhewar BamniBk]

Jeanne Boyarsky wrote:

I have another static analysis rule that flags when a method parameter gets set. That rule is higher severity than the one to use the final keyword.

Jeanne, it would be great if you explain me this static analysis rule which you are talking

[David Newton]

@Campbell: I'd guess I'm probably remembering it wrong and it was split up into several methods. Although once it was bytecode it probably wasn't all that big--I'll get someone to send it to me and post on meaningless.

[Campbell Ritchie]

It's not quite as bad if it's in separate methods.

[Jeanne Boyarsky]

hemant Budhewar BamniBk wrote:Jeanne, it would be great if you explain me this static analysis rule which you are talking

Here's the link for the rule in PMD. I don't think Checkstyle has it. The rule checks whether you assign a new value to a method parameter. If you do, it triggers a rule violation. Which means I don't have to sit there adding final to my actual code to be sure that I'm not reassigning the parameters.

[David Newton]

http://checkstyle.sourceforge.net/config_coding.html#ParameterAssignment