Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not declare local variables as final #11

Open
cbeams opened this issue Jun 6, 2018 · 2 comments
Open

Do not declare local variables as final #11

cbeams opened this issue Jun 6, 2018 · 2 comments

Comments

@cbeams
Copy link
Contributor

cbeams commented Jun 6, 2018

It is highly desirable to declare member variables (both static and instance) as final in order to advertise and enforce the statelessness and immutability of a given class. It is, however, not desirable to declare local variables as final for the following reasons:

  1. It is not the idiom in Java to do so. This is not to say that people never do it, but that if you scan the majority of large, popular open source Java codebases, you will find that most local variables are not declared final, and that where they are, it is done in a way inconsistent with the rest of the codebase.

  2. There is typically no need to declare local variables as final. There are certain cases, such as when a variable is declared and then subsequently used within an anonymous class, but this is rare, and even more rare since Java 8 and lambda expressions, which transparently handle local variables as "effectively final" without any explicit final modifier necessary.

  3. If final is considered "necessary" because you want or need to prevent mutation, your method is probably too complex. Methods should be simple and typically quite short. There should be no need to "enforce" immutability of a local variable in the context of a method. Its purpose should be obvious, and it should be obvious if overwriting the value of the variable is the wrong thing to do.

  4. Applying the final modifier to local variables creates line noise without creating any value. The use of final on local variables is doubly distracting to the reader, (a) because it is that many more characters that the reader needs to parse and (b) because as noted in (1) above, it is non-idiomatic to see, meaning that it catches the reader's eye all that much more, and makes them wonder (needlessly) "why is this variable declared final?", only to eventually realize that it didn't need to be final at all, and that this modifier was just a waste of their time.

  5. Java 10 introduces the reserved type name var for convenient declaration of local variables, but there is no way to declare a var as final (whereas in Scala, for example, this is done with a distinction between var (mutable) and val (immutable) declarations). This means that in Java 10, it will become even less idiomatic to see final local variables, and that you'd need to really go against the grain to declare them that way.

cbeams added a commit to ManfredKarrer/archived-bisq-core that referenced this issue Jun 6, 2018
@ManfredKarrer
Copy link

Finally found how to change the behavior in IntelliJ when you extract a variable (it makes it final by default).
The checkbox is enabled by default:
screen shot 2018-06-06 at 22 54 56

Disable it and IntelliJ remembers the decision.
screen shot 2018-06-06 at 22 55 07

@christophsturm
Copy link

that sounds like a strange rule to me. immutability is important, in kotlin or scala everything is a val (const=final) by default and vars are very rare. mutable variables are a code smell, and usually a sign that you should rewrite in a more functional way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants