Hello,

I’m trying to avoid re-assigning local variables whenever it’s possible. For me 
it makes the code easier to reason about - I know that the variable “state" 
created at the beginning of the method is the same one I can access at the end. 
If I need the child state at some point I can create the new variable. The same 
applies for the parameters (I think it’s some kind of code smell to reassign 
parameter anyway).

For this reason I put the dreadful “final” keyword before each variable 
declaration. It allows me to put some of the responsibility on the compiler. I 
don’t add the “final” to the parameter names, cause I like the method 
signatures to fit in one line. I also understand that this is subjective matter 
and I’m sure there is a lot of better programmers than me that don’t need 
finals. That’s why I vote for the (b).

Best regards,
Tomek




On 28/08/15 08:36, "Thomas Mueller" <[email protected]> wrote:

>Hi,
>
>I wonder what does the team think about using "final" for variables and 
>parameters. In Oak, so far we didn't use it a lot. This question has come up 
>with OAK-3148. The patch uses "final" for variables, but not for parameters. 
>Lately, I have seens some code (I forgot where) that uses "final" for 
>parameters in an _interface_. Please note this is not about using "final" for 
>fields, where I think everybody agrees it should be used. It's just about 
>variables and parameters.
>
>I think we have 3 options:
>
>(a) use "final" for variables and parameters everywhere possible
>
>(b) let the individual developer decide
>
>(c) don't use it except if needed
>
>Some links:
>http://stackoverflow.com/questions/154314/when-should-one-use-final-for-method-parameters-and-local-variables
>http://stackoverflow.com/questions/137868/using-final-modifier-whenever-applicable-in-java
>
>Personally, my favorite is (c), followed by (b). As for (a), I think (same as 
>Alex Miller at StackOverflow) it clutters the code and decreases readability. 
>Too bad "final" is not the default in Java, but Java will not change, and we 
>are stuck with Java. I think using "final" will not improve the code, because 
>people don't "accidentally" change variables and parameters, so it will not 
>help the writer of a method, it will not help the compiler or performance (the 
>JVM can easily see if a variable or parameter is effectively assigned only 
>once). To improve the code, I'm all for using Checkstyle, unit tests, code 
>coverage, mutation testing, enforcing to write Javadocs for interfaces, and so 
>on. But using "final" wherever possible, I think it would be a step backwards.
>
>Regards,
>Thomas
>

Reply via email to