The real reason here is subtle: I do not use final on classes or methods because it prevents mocking. True, we're never going to mock a private static inner-class, but again, this becomes an example that other developers start to copy. Adding `final` to this inner-class does not provide any value. And in fact it actually increases the amount of code and it adds _noise_ to the code. Noise causes a delay when a developer studies the code. So you have to ask: if I add this to the code, does it provide any value including being more easy to maintain or quicker to understand. I try to minimize noise in every class I touch. I also try to make the class/test follow the best practices and coding conventions that are in the books, articles and examples. We also have a best practice or coding standard in Geode to not make methods or classes final unless there's a very strong reason to do so. This was on the dev-list a few years ago, when I proposed avoiding the use of final on classes and meth ods and removing final from all class and method declarations to help facilitate using Mockito. There was a large commit that removed final from these declarations across the entire code base.
The only places of value to use `final` in Geode are: 1) on member fields, 2) (this is much less useful than `#1`) parameters passed into a method, 3) class in User API that must never be extended. The only reason for `#2` is because if we're consistent, then it gives immediate information to a developer that the parameter is never reassigned, and even then it doesn't have much value if the method is small (as all methods should be). As far as I know we have no examples of `#3`. I think that the reason people keep reintroducing `final` in weird places is because they're using other code in the codebase as an example and we never did a sweep to clean it up. [ Full content available at: https://github.com/apache/geode/pull/2978 ] This message was relayed via gitbox.apache.org for [email protected]
