0

It is generally a good idea to restrict access to your variables as much as reasonably possible. For example make things private instead of publicand make variables final if they aren't supposed to change. I believe the same applies to method parameters, but I find actual practice of this to be extremely rare.

For example, no IDEs that I know of offer warnings for finality of method parameters, even though you should be able to tell easily if the parameter can be made final. Even core Java libraries don't make their method parameters final, even though they could; and I find it pretty rare for a 3rd party library to do this either.

Overall the benefits here are certainly relatively low, given that the scope is so small. Does it give enough benefits though to justify as a coding standard?

David says Reinstate Monica
  • 2,739
  • 2
  • 18
  • 24
  • No. Until somebody cites an example where it matters, this is a waste of time that clutters your code. In Java, what does the final parameter even do or prevent? – user949300 Sep 27 '17 at 01:05
  • I think this is primarily opinion based, so I'm voting to close. IMO the scope is small enough and reassigning arguments in a method is such a unusual thing to see that while it would be syntactically more correct, it isn't important to mark them final. It may be better to have a compiler plugin that errors when parameters are assigned to. – Samuel Sep 27 '17 at 01:17
  • This to me sounds like the definition of boiler plate that people complain about in Java. Along the same lines where all local variables are final but then objects keep on getting mutated by their methods. – Hangman4358 Sep 27 '17 at 02:10
  • @Samuel If OP would rephrase to ask "whats a concrete example of a final parameter making an improvement" that, IMO, would be worthwhile. – user949300 Sep 27 '17 at 02:50
  • @user949300 Any time you use a `final` parameter, you can simply omit `final` and the code will work with the same behavior. `final` is about what you cannot do, and thus what assumptions you can make. So instead you'd want examples of confusing or broken code that would have been disallowed had the parameter been `final`. – Derek Elkins left SE Sep 27 '17 at 03:07
  • @Derek Elkins agreed. However, i have never encountered, nor can i think of, any half-sane code where `final` on a **method parameter** prevents something from breaking. If I change an incoming `int` or object reference, nobody on the outside will see it, so why bother making it final? – user949300 Sep 27 '17 at 03:14
  • @user949300 Parameters are usually treated as if they are `final` anyways, so there's already the expectation that the parameter binding won't be mutated. Of course, when that expectation is violated, either intentionally or unintentionally, it becomes especially surprising. One of the benefits of using `final` whenever possible, is that when you *don't* use it, you are clearly communicating "something unusual is happening". Ultimately, at the very least for parameters, this is just a poorly chosen default by Java. – Derek Elkins left SE Sep 27 '17 at 03:31
  • Possible duplicate of [In Java, should I use "final" for parameters and locals even when I don't have to?](https://softwareengineering.stackexchange.com/questions/48413/in-java-should-i-use-final-for-parameters-and-locals-even-when-i-dont-have-t) Also [Why should I use the keyword “final” on a method parameter in Java?](https://stackoverflow.com/questions/500508/why-should-i-use-the-keyword-final-on-a-method-parameter-in-java) – Derek Elkins left SE Sep 27 '17 at 03:33

0 Answers0