I'm not very fond of a plague of finals. Here's why.
Consider
final int[] x = new int[10];
That doesn't, sadly, prevent
x[2] = 1;
So, to me, final is too weak to be useful. I put them in code when
required due to the rules about anonymous functions capturing locals,
but never otherwise.
Just my 1cent on this subject.
On Sat, Feb 13, 2010 at 3:21 PM, Robin Anil <robin.a...@gmail.com> wrote:
> Only done for local fields. And handpicked ones in bayes for local variables
> due to openXXYYHashMap.foreach() requiring final objects
>
>
> On Sun, Feb 14, 2010 at 1:47 AM, Ted Dunning <ted.dunn...@gmail.com> wrote:
>
>> I find final slightly helpful on fields, very helpful on static fields, but
>> not very helpful at all on local variables. The issue is scale. With a
>> field there are lots of places you can bugger it up. If the scope of a
>> local is large enough for similar confusion, you have a different problem
>> anyway.
>>
>> I am generally -1 to too many final declarations on parameters and local
>> variables, but I don't go to the trouble of deleting them if I see them.
>>
>> On Sat, Feb 13, 2010 at 11:03 AM, Sean Owen <sro...@gmail.com> wrote:
>>
>> > I'm late on this but have a question about the final business. I
>> understand
>> > the style it is promoting and even like it and used to do it. I stopped
>> > because it does get harder to read and its not usual in java code. Any
>> > thoughts on that.
>> >
>> > On Feb 13, 2010 2:55 PM, "Robin Anil" <robin.a...@gmail.com> wrote:
>> >
>> > I just did a mass code cleanup.
>> >
>> > Mainly comprising of
>> > -Extra blank line removal
>> > -Organize Imports across all packages.
>> > -Making local variables final
>> >
>> > No reordering of methods or code style changes are applied.
>> >
>> > Any objections or any particular class to withhold from committing.
>> >
>> > Robin
>> >
>>
>>
>>
>> --
>> Ted Dunning, CTO
>> DeepDyve
>>
>
