0

I asked a collegue why he used final keyword for the assignment in this method and his response was, "Why not?". I don't see the benefit of putting final here. Or often times, I see it in class definitions as well.

protected void sendIndexWorkflowRequest(Status status)
{

    final long contextId = status.getAppContextId();
    PrepareIndexPostData preparePostData = new PrepareIndexPostData.Builder(contextId).build();

    searchIndexService.activateAggsIndex(preparePostData);
}
Horse Voice
  • 8,138
  • 15
  • 69
  • 120
  • It's more explicit that the variable is never changed. This (case) is a matter of opinion, it is not required by the language. – Sotirios Delimanolis Oct 20 '14 at 15:31
  • apart from exceptional cases, if you need to use `final` on a local variable to make it clear that it does not change, it is very likely that your method is too long... – assylias Oct 20 '14 at 15:33
  • I'd consider it as a safety in messy methods where the reference might be re-assigned by mistake. Otherwise, pretty pointless. – Mena Oct 20 '14 at 15:34
  • So I see this as more of a documentation than anything else! – Horse Voice Oct 20 '14 at 15:34
  • Usually for readability, but could be a needed constraint (like it's used twice but must have same value both times). – NESPowerGlove Oct 20 '14 at 15:35
  • It is simple good practice to do so. The same to encapsulate members with private and access only thru getter/setter, catch Exception properly, etc, etc. All that stuff we know we should do and we don't. – PeterMmm Oct 20 '14 at 15:36
  • Also `final` is usually quite important on multi-threading cases, to ensure that a variable will not change and thus all threads will see the same value. – m0skit0 Oct 20 '14 at 15:42
  • @m0skit0 That's not relevant for local variables. – Marko Topolnik Oct 20 '14 at 16:44
  • 2
    Basically, the language would have been better if `final` was the default and a special modifier was needed on a mutable variable. Most local variables are effectively final. – Marko Topolnik Oct 20 '14 at 16:46

2 Answers2

6

He's asserting that that variable mustn't change within the method. It's essentially a coding safety check. i.e. the compiler will raise an error if the variable is re-assigned to (most likely accidentally) and is often regarded as a good practise.

You may see something similar with method parameters e.g.

public void method(final Object a) {
  // ...
}

which asserts that the Object 'a' reference shouldn't change within the method. You may want to change it at some stage (in which case remove the final) but leaving it as final whilst you don't need it to be mutable may protect you against coding errors.

Note that final variables will be required if you're referencing such variables within an inner class (now not a requirement with Java 8, which can determine non-final variables as being effectively final)

Community
  • 1
  • 1
Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
  • But in the end it is up to whoever comes later to decide whether it is final or not. So, I dont see the point in defining as final a variable used only once. – luanjot Oct 20 '14 at 15:43
  • You can always refactor and make mutable later, yes. But that's a concious decision. If it isn't then the final will protect you (hopefully) – Brian Agnew Oct 20 '14 at 15:44
0

It is best practice so you dont end up reusing local variable and would be helpful in future to refactor such method.

SMA
  • 36,381
  • 8
  • 49
  • 73