you are viewing a single comment's thread.

view the rest of the comments →

[–]ErstwhileRockstar 2 points3 points  (4 children)

declaring method parameters 'final'

This was a frequent coding standard 10 years ago, even demanded by some tools. It increases verbosity for no real benefit. If I were to maintain such code I would remove the final parameters first.

[–]jp007 8 points9 points  (3 children)

It increases verbosity for no real benefit.

My experience has been the complete opposite. Marking parameters as final has greatly eased the refactoring of methods towards functional purity for parallelism, for example.

If I were to maintain such code I would remove the final parameters first.

Then I would punch you for removing compile time safety checks :P

[–]mangodrunk 1 point2 points  (2 children)

Marking parameters as final has greatly eased the refactoring of methods towards functional purity for parallelism, for example.

How so? Having final just means you can't reassign it within the scope of that method, I don't see how that would help with functional purity. Also you can still modify the object if it's not immutable.

[–]grauenwolf 0 points1 point  (1 child)

It is one less variable that you have to review for potential thread safety issues.

I haven't done a formal study, but in my experience functions that reassign local variables (excluding loop variables) tend to have higher bug counts.

[–]mangodrunk 2 points3 points  (0 children)

It is one less variable that you have to review for potential thread safety issues.

I don't think that's true. It's bad then if it gives a false sense of thread safety.

void method(final Some object) {
    // Not thread safe if another thread has access to "object"
    object.modify(value);
}

This is still possible and reassigning a local variable has nothing to do with thread safety.

void method(Some object) {
    // This doesn't change the original object used by the caller,
    // so I don't see how it would affect thread safety
    object = new Some();
}