Timeline for In Java, should I use "final" for parameters and locals even when I don't have to?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 20 at 21:02 | comment | added | Azuaron | In your "without final" example, you say that it's, "Simple. Clean. Everyone knows what's going on." Except, it results in an extremely common misunderstanding in Java. Method parameters are passed by reference, but the references are passed by value. Many people look at that code and conclude, "When I finish this method, the parameter I sent into 'doSomething` will now be lowercase." This is not the case; the original stays as it was. To head off this confusion, it's nearly always better to create new variables instead of performing something that looks like a durable mutation, but isn't. | |
| Jul 19, 2023 at 17:37 | comment | added | Samurai Soul | Why would you ever want a unit test to uncover an issue that could be prevented by the compiler? | |
| S Feb 14, 2023 at 12:22 | history | suggested | hc_dev | CC BY-SA 4.0 | add Sonar with link to rule |
| Feb 10, 2023 at 11:13 | review | Suggested edits | |||
| S Feb 14, 2023 at 12:22 | |||||
| Jul 5, 2020 at 16:46 | comment | added | PlexQ | This is where a functional decorator would win the day. withLowerCased(input, input -> {...method body }); public <T> T withLowerCased(String input, Function<String, T>) { return f.apply(input.toLowerCase()); }. Now we can honor immutability, not add an exception path (which in my opinion breaks SOLID), and avoid local reassignment. | |
| Oct 23, 2019 at 15:05 | comment | added | blubberdiblub | I find the point that one may mistakenly use input instead of lowercaseInput moot. While technically correct, it's an easy to spot mistake once it causes you a bug, as you can clearly see the different semantics of the 2 separately named variables at their point of usage (provided you give them good names). To me, it's more dangerous to conflate 2 semantically different usages of separate values into the same variable and therefore the same name. It can make tracking down bugs more difficult, as you'll have to read and understand all preceding code that's somehow related to the 1 variable. | |
| Aug 26, 2016 at 14:46 | history | edited | Bohemian | CC BY-SA 3.0 | added 1247 characters in body |
| Aug 26, 2016 at 4:50 | comment | added | maaartinus | +1 for pointing to the risk "that code further down may use input". Still, I'd prefer my parameters to be final, with a possibility to make them non-final for cases like above. It's just not worth spamming the signature with a keyword. | |
| Aug 26, 2016 at 2:29 | comment | added | Andres F. | In the last case, final does provide the partial guarantee that you're dealing with the same Date instance. Some guarantees are better than nothing (if anything, you're arguing for immutable classes from the ground up!). In any case, in practice much of what you say should affect existing immutable-by-default languages but it doesn't, which means it's a non-issue. | |
| Aug 26, 2016 at 1:28 | history | answered | Bohemian | CC BY-SA 3.0 |