Moving the discussion to this thread. Sorry for starting off with a VOTE. I'm primarily interested in Maintainability https://en.wikipedia.org/wiki/Software_quality#Maintainability, and my concern regarding using "final" on method parameters or local variables is about Code Readability: understanding what the code does at a glance and being able to spot bugs and mistakes more easily.
Infrequently used keywords such as "final" on method parameters and local variables cause "noise" for me such that it slows down my understanding of what the code does. I find that I have to spend more time studying it and it takes longer than a "glance." Now, if the keyword buys us enough to justify the "noise" then it's worth it (such as for long methods), but I am arguing that small methods of a dozen or less lines do NOT benefit from having "final" on any of its variables or parameters. I also really, really, really want to encourage this community to refactor the code. In other words, if you touch a long method, PLEASE refactor it to break it up into smaller, well-named methods with descriptive parameters and local variables that are only ever assigned once. Then each method is very easy to understand at a glance and we no longer need "final" on any of its vars or params to indicate that it is never reassigned... because we know at a glance that it's only assigned once. Developers also have a tendency to look at code and then emulate it. If they're looking at phenomenally long methods that aren't unit tested and have short non-descriptive var names, then they're going to repeat that both when maintaining such code and when writing new code. We don't want that, or at least I don't want that. Consistency (such as always using "final" on all method parameters) results in the developer getting used to it and expecting it so that you recover some of that speed in understanding what you're studying without stumbling over "noise" or unnecessary syntax and structures. I believe that simplicity and understandability is more important than having the "final" keyword on just one out of five parameters on one method. As I refactor the code, I make sure that the methods end up short and succinct so that "final" is no longer needed on that one parameter. Introducing a coding standard would help us immensely. The standard can include important things like: * Use descriptive variable and method names that are spelled out. * Keep the methods short. There are tons of best practices, corrections for code smells, and conventions for highly readable and maintainable code that we could and should be adopting. The bottom line is I don't really care about "final" -- using it or NOT using it -- what I care about is code quality and making the code readable and maintainable while following a well-thought out and group-written coding standard. -Kirk
