Why declare final variables inside methods?

  • Studying some classes of Android, I realized that most of the variables of methods are declared as final.

    Example code taken from the class android.widget.ListView:

    /**
    * @return Whether the list needs to show the top fading edge
    */
    private boolean showingTopFadingEdge() {
        final int listTop = mScrollY + mListPadding.top;
        return (mFirstPosition > 0) || (getChildAt(0).getTop() > listTop);
    }
    
    /**
     * @return Whether the list needs to show the bottom fading edge
     */
    private boolean showingBottomFadingEdge() {
        final int childCount = getChildCount();
        final int bottomOfBottomChild = getChildAt(childCount - 1).getBottom();
        final int lastVisiblePosition = mFirstPosition + childCount - 1;
        final int listBottom = mScrollY + getHeight() - mListPadding.bottom;
        return (lastVisiblePosition < mItemCount - 1)
                         || (bottomOfBottomChild < listBottom);
    }
    

    What is the intention of using the final keyword in these cases?

    One can flip this around and ask: why declare non-final one-time variables inside a method? Perhaps they make it final unless it absolutely does not need to be. I would say that this is not a bad practice - you are more likely to avoid a couple of bugs, save a few seconds for some readers. Also, seasoned C++ hackers might get a lukewarm, albeit not warm, semi-fuzzy feeling from using final, which is like const. Doing this has the same benefit as what I call "assert-driven development". Since what can go wrong will go wrong, why not take cheap insurance against it? State modification canb evil.

    Probably they're in place to pass static code analysis tools such as PMD.

  • Jon

    Jon Correct answer

    9 years ago

    I would say that this is due to force of habit. The programmer that wrote this code knew as he was writing it that the values for the final variables should never be changed after assignment, and so made them final. Any attempt to assign a new value to a final variable after assignment will result in a compiler error.

    As habits go, it's not a bad one to develop. At the least, making a variable final specifies the intent of the programmer at the time of writing. This is important as it might give subsequent programmers who edit the code pause for thought before they start changing how that variable is used.

    I would add (and did add in my answer) that declaring variables final by default is also a good habit because it encourages you do make fields final by default as well.

    Agreed. It's a good habit to get into along with a number of others; eg: "Make everything final by default, unless otherwise required", "Make everything private by default, unless otherwise required".

    well, ya, but there are a couple of good reasons behind the habit

    Calling it a "habit", IMO, gives a negative connotation. It's a good practice: declare a variable how you intend for it to be used. I realize you agree, just thought I'd throw it out there.

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM