[matt2000]

I agree, and I'm not sure how something like 'var accounts = calculateAccounts(something)' can be thought of as better in a code review setting. I suspect using "var" or equivalent will be considered a problem by most companies within the next few years.

[tombert]

This experiment has already been run with pretty much every language that isn’t Java or C, and I think most people have been ok.

Yes, code review is arguably worse, but most people who write Java do so with an IDE and the type is never unknown at that point.

Also, if your function is big enough to where the type of var is not very clear, it likely shouldn’t be passing code review regardless.

[nunobrito]

Those writing in python and javascript don't honestly know any better. They grew in a world without unit testing or without products that need to grow into gigantic systems maintained over the next decades.

This reminds me of a developer writing in jRuby because "it was better". While he was in the company he'd still give support to his own works, after leaving nobody else wanted to pickup those "better" things and would prefer to write workarounds to the tool, it effectively became a black box that few could improve and even worse to test. As result, those portions had to be rewritten in proper Java so that we'd be able to deeply measure/test and improve.

Never again.

[vips7L]

There’s nuance in programming. Both of these statements can be true. Var reduces boiler plate when you’re duplicating information in both the lvalue and rvalue.

I’m in agreement that when the information isn’t in the rvalue that you shouldn’t use var.