On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote: > > It all depends on what "..." contains doesn't it? If it's a simple > one-liner-single-method-call-with-no-args, the "final" may seem overkill, but > it is more complex it is not IMO. This is all about communicating intent. I > prefer to use final consistently than making a judgement call on whether this > or that declaration benefits. Either the value is constant or it is not.
Yes, it is true that what "..." contains matters. I would argue that in the specific case of LogManager that within the static block the declarations of managerProps, factoryClass and cl are worthy of being declared final. All the rest are unnecessary. However, it is just a matter of opinion and not something worth fighting about (but definitely worth discussing just because it is interesting). > > > While I have no great objection to this I find it to be of minimal value. In > general, methods and blocks should be fairly short so the "clarity" declaring > these variable final provides isn't of much value to me. > > Great point, "clarity" yes, but clarity *of intent* is my goal, which is > different than clarity of coding in the fewest amount of characters a la C. > I'm no great believer of "self-documenting" code, but using final helps say > "this name is not a variable, it is a constant". Interesting argument. But I would argue that none of the local variables marked as final (even the variables I noted above) are actually "constants". Rather, they are variables whose values do not happen to change within the block of code they occur in. From that point of view, I'm not really sure I care. If I need to come along tomorrow and cause the value to change for whatever reason I'm going to do it. Since that would happen within the scope of a few lines of code having the final keyword doesn't help me much. Ralph
