"No you can't use Java 11's `var` because other developers will [be boomers about it and unable to check types by hovering over variables for half a second]" - my team, basically

_Ok, DuckDuckGo_, use cases for var in Java

Yep, that's java in 2020. Ignoring new features because they're new.

@c3r38r170 Mainly to reduce the inherent redundancy of shit like
Something something = new Something();

But I can hover over auto and see the type in C++. Maybe java just be shitty?

I hate this stupid argument...
Every time a language gets a new feature, there is resistance from half the team to adopt it because "it's confusing" and "nobody needs that". 🤬

Well... I like to adopt new things from java, but 'var' is not one of them. I do use it here and there in max 3loc blocks of code, but definitely not extensively

also, one is not always using an ide. No, I don't mean a notepad - I mean git's gui: bb, bl, gh, etc. Some teams might not even have an ide to hover a mouse in...

Speaking from experience

@Demolishun Has nothing to do with the language and any Java IDE can show the actual type on hover

@12bitfloat The leaps of illogic I express are intentional.

@12bitfloat
Me: "var stuff = new ArrayList<Things>();"
Java Peeps: "but how even will I know what type stuff is?!"

@localpost So you omit a "Something". Huh.
I mean it's cool, I'm adopting it.

@SortOfTested
`var value = SomeFactory.fetchValue();`

Or even better..

```
var items = someRepo.getAll()
items.forEach(it -> it.<...do what exactly...? wtf is the type here???>)
```

and off you go to find the SomeFactory to figure out wtf it's returning. It's fine when in an IDE which knows how to map. Kind of sucks in BB, GH or GL UI).

Sucks a lot when you are not a dev in the project but need to browse its code. You don't have permissions to the artifactory and to compile the damn thing, so even the IDE is unable to do the mapping for you.

No. I don't think usage of `var` all over the place is a great idea. Especially when the IDE can generate your variable declaration based on the function's return type. It's just 3 clicks away - no need to type all of it.

@netikras
That's also the exact antipatterns they discuss in the documentation and language commentary.

https://openjdk.java.net/projects/...

Adding var just feeds into the Java vs Javascript confusion. Its a nice feature, but whole classes of programmers won't know what language they are using.

@Demolishun
Especially now that var makes you persona non-grata in javascript. Let and const are the only acceptable dimension operators. /s

@SortOfTested Uh oh... I use var all the time. Am I going to hell?

@Demolishun
Worse, you're going to jsconf

@SortOfTested Now I want to go! Talk to people about my mission to spread JesusScript across the land.

@Demolishun
Terry Davis would be proud. And suspicious, and sad, and inspired, and anxious.

@SortOfTested Unless you're referring to the G3 guideline, I can't find it. Also, G3 only solves (do guidelines actually _solve_? Or just suggest how to solve most of the problems?) the problem partially, as >90% of the methods are already written in a way that doesn't comply to this guideline. Simply because var was not in the picture at the time of writing. Rewriting it all is a time and resources burner for a very questionable benefit.

NOT rewriting those methods contradicts with the G3. What's left then? Mixing var and the classic declaration, which burns the code consistency immediately.

Also, @localpost, please mind the P3 [https://openjdk.java.net/projects/...]

@netikras
var doesn't add any mental overhead in the cases where it's used to eliminate redundancy. Its actually fairly consistent with another pattern already as lambda argument types are inferred.

About half of java devs followed the previous guidance correctly. It wasn't to reiterated the type of the left side, it was to type the left side as the most generalized abstraction. Which was generally not autocompleteable and required people to look at the class impl to determine what it is, sometimes drilling through several layers of nested inheritance.

@SortOfTested Yes, I agree with that. However, most generalized abstraction is a long way from an inferred abstraction. In the case of the most general left-side we *know* what the type is. G3 suggests that it could be replaced with `var` *if* the method name suggests the returned type.

Now have 50% of the devs been following this rule? Do method names usually suggest the actual type? Of all the code I've seen people usually name their methods by the action they perform. Sometimes they include some entity name in it, but in nearly all the cases that entity name is only approximate, e.g. createCart(Account): CustomerCart, where the application has a variety of Cart entities: CustomerCart, UninitializedCart, CartImpl, ExtCart, etc.

My point is, while the idea is nice, the current code is almost a good fit for it. However, converting 'almost' into 'complete' requires substantial effort (mind the dependencies).