aspose file tools*
The moose likes Java in General and the fly likes CheckStyle Rule : Making final to the local variables Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "CheckStyle Rule : Making final to the local variables" Watch "CheckStyle Rule : Making final to the local variables" New topic
Author

CheckStyle Rule : Making final to the local variables

hemant Budhewar BamniBk
Ranch Hand

Joined: May 09, 2009
Posts: 33
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
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
How does labelling local variables final make code difficult to read?
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

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.


[Jess in Action][AskingGoodQuestions]
Anirudh Vyas
Ranch Hand

Joined: Oct 23, 2006
Posts: 93
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!



Vyas, Anirudh
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

How does making a variable "final" make code more OO?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
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
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

...

How does making local variables final make it easier to make code more OO?
hemant Budhewar BamniBk
Ranch Hand

Joined: May 09, 2009
Posts: 33
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
Marshal

Joined: Mar 22, 2005
Posts: 39548
    
  27
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.


Ping & DNS - updated with new look and Ping home screen widget
hemant Budhewar BamniBk
Ranch Hand

Joined: May 09, 2009
Posts: 33
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
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
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
Ranch Hand

Joined: May 09, 2009
Posts: 33
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
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
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
Ranch Hand

Joined: May 09, 2009
Posts: 33

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
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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
internet detective
Marshal

Joined: May 26, 2003
Posts: 29249
    
139

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
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
    Ranch Hand

    Joined: May 09, 2009
    Posts: 33
    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
    Ranch Hand

    Joined: May 09, 2009
    Posts: 33
    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
    Author
    Rancher

    Joined: Sep 29, 2008
    Posts: 12617

    @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
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36508
        
      16
    It's not quite as bad if it's in separate methods.
    Jeanne Boyarsky
    internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 29249
        
    139

    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
    Author
    Rancher

    Joined: Sep 29, 2008
    Posts: 12617

    http://checkstyle.sourceforge.net/config_coding.html#ParameterAssignment
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: CheckStyle Rule : Making final to the local variables
     
    Similar Threads
    marcuz green example
    CheckStyle Rule : Making final to the local variables
    wrong answer???
    final local variable question
    Final modifier and Java performance tuning