3 ms·

Although I do agree that you shouldn't reassign a parameter I don't agree with using the final keyword everywhere. Any decent koder knows not to modify a param

Although I do agree that you shouldn't reassign a parameter I don't agree with using the final keyword everywhere. Any decent koder knows not to modify a parameter. If you want to enforce something like this then parse the code on check in and refuse the check in if a parameter is modified. Don't bloat the kode with a reactionary workaround.

scott_s 17y ago
I program extensively in C++, not Java. I'm in the habit of using the const qualifier wherever appropriate - even if it's a local variable. It's an easy way to tell myself, others and the compiler that what I'm declaring isn't actually a variable, but a named value. I don't see how using a const or final qualifier where appropriate increases bloat.
profquail 17y ago
So having to write extra code to extend your versioning system to parse whatever language your code is in and then check it to see if you've altered a variable value doesn't increase bloat, but adding the 'final' keyword does? There are other problems with that idea, the first of which is that if someone else takes your code and extends it (say, for an open source project) they won't have the same "checking system" that you have, and so it won't catch their mistakes (while using "final" would). Also, I'm not a Java programmer (I mostly use C# or C), but marking classes/methods/variables in C# as 'sealed', 'final', 'static', etc. actually increases the running speed of that program on the CLR because it is able to skip some safety checks on the IL code when it is executed; I don't know that the JVM does that, but it might be worth looking into.
- gdp 17y ago
  Most JVM implementations that I am aware of do sane things with respect to optimisation of immutable values.
Tichy 17y ago
I would use final if something is final because it would also help to understand the code. It is a piece of information that something is final. Don't forget that final things can still be changed, though. somethingFinal.setName("teehee"); is still possible even if somethingFinal is final.
- gdp 17y ago
  Sure, but that would be deliberately going against the tips in the article. The idea is to not mutate values, rather, you instantiate new objects to store new values.
fogus 17y ago
"parse the code on check in and refuse the check in if a parameter is modified" This would be know as really-really-late-binding.

scott_s 17y ago

I program extensively in C++, not Java. I'm in the habit of using the const qualifier wherever appropriate - even if it's a local variable. It's an easy way to tell myself, others and the compiler that what I'm declaring isn't actually a variable, but a named value. I don't see how using a const or final qualifier where appropriate increases bloat.

profquail 17y ago

So having to write extra code to extend your versioning system to parse whatever language your code is in and then check it to see if you've altered a variable value doesn't increase bloat, but adding the 'final' keyword does? There are other problems with that idea, the first of which is that if someone else takes your code and extends it (say, for an open source project) they won't have the same "checking system" that you have, and so it won't catch their mistakes (while using "final" would). Also, I'm not a Java programmer (I mostly use C# or C), but marking classes/methods/variables in C# as 'sealed', 'final', 'static', etc. actually increases the running speed of that program on the CLR because it is able to skip some safety checks on the IL code when it is executed; I don't know that the JVM does that, but it might be worth looking into.

gdp 17y ago
Most JVM implementations that I am aware of do sane things with respect to optimisation of immutable values.

Tichy 17y ago

I would use final if something is final because it would also help to understand the code. It is a piece of information that something is final. Don't forget that final things can still be changed, though. somethingFinal.setName("teehee"); is still possible even if somethingFinal is final.

gdp 17y ago
Sure, but that would be deliberately going against the tips in the article. The idea is to not mutate values, rather, you instantiate new objects to store new values.

fogus 17y ago

"parse the code on check in and refuse the check in if a parameter is modified" This would be know as really-really-late-binding.