Comment by Supermancho
Comment by Supermancho 3 days ago
Can someone explain why developers like var?
Comment by Supermancho 3 days ago
Can someone explain why developers like var?
To me var is what makes modern java somewhat readable and more bearable. It was always a joke that it takes too long to write anything in java because of the excessive syntax repetitions and formalities. To me that joke is heavily based on a reality that modern Java is tackling with this quality of life features.
I get the attraction to var, but I, personally, don't use it, as I feel it makes the code harder to read.
Simply, I like (mind, I'm 25 year Java guy so this is all routine to me) to know the types of the variables, the types of what things are returning.
var x = func();
And, yes, I appreciate all comments about verbosity and code clutter and FactoryProxyBuilderImpl, etc. But, for me, not having it there makes the code harder for me to follow. Makes an IDE more of a necessity.
Java code is already hard enough to follow when everything is a maze of empty interfaces, but "no code", that can only be tracked through in a debugger when everything is wired up.
Maybe if I used it more, I'd like it better, but so far, when coming back to code I've written, I like things being more explicit than not.
1. Just because you can use var in a place, doesn't mean you should. Use it where the type would be obvious when reading code like
var myPotato = new PotatoBuilder.build(); var myFood = buyFood();
2. Even if you don't follow 1, IDEs can show you the type like
var Potato (in different font/color) myFood = buyFood();Yes, well expressed. For that case using var is not a wise approach.
It does help when writing:
var x = new MyClass();
It's called type inference and it's the way things should be. You get the same types but you don't have to spell them out everywhere. Java doesn't even go all the way, check OCaml to see full program inference.
OCaml's type inference is truly amazing, makes it such a delight to write statically typed code - reading it on the other hand...
But I think that's easily solved by adding type annotations for the return type of methods - annotating almost anything else is mostly just clutter imo.
Annotations would be a substitute for writing the return type. Extra code for a shortcut seems like the worst solution.
I don't mean Java annotations, those would be too clunky - in OCaml a type annotation is really just adding `: <typename>` to variables, function return types, etc.
so fibonacci could look like this
```
let rec fib n =
match n with
| 0 -> 1
| 1 -> 1
| _ -> fib (n - 1) + fib (n - 2)
or with annotations it becomes this:
```
let rec fib (n: int): int =
// Same as above :)
It's another thing they adopted from Kotlin, since Kotlin is supposed to be a "better java". Now Java is retroactively adopting Kotlin freatures.
Kotlin didn't invent type inference, it's a feature from ML.
I never said Kotlin invented type inference, just that the syntax was straight adopted from kotlin
It‘s a harmful code smell: It often obfuscates the type, forcing you to actively check for the type and should not be used.
Languages should not be designed around the assumption that people use an IDE.
It can. But seeing the text there is faster than having to hover to see what the type is.
It exists. It’s fine. People obviously like it.
Some don’t, I’m one of them. I don’t see the advantage is very big at all. I don’t think it’s worth the trouble.
But that’s me.
Bingo.
Sometimes I doubt most hacker news commentors have ever worked in big corpo environments where you have to regularly review large PR in some broken webapp like GitHub.
This is what it looks like to me. If you wanted to do this, why not use a scripting language where you can use this kind of practice everywhere? In Java, I don't expect to have to look up the return type of something to discover a variable type. Graciously, I can see how you can save rewriting the Type declaration when it's a function return you want to mutate.
Generally, you save some keystrokes to let other people (or future you) figure it out when reading. It seems like bad practice altogether for non trivial projects.
Modern IDEs will show you the type of anything at all times. I do not understand your point unless you're doing raw text editing of Java source.
Those keystrokes are not just saved on writing, they make the whole code more legible and easier to mentally parse. When reading I don't care if the variable is a specific type, you're mostly looking whats being done to it, knowing the type becomes important later and, again, the IDE solves that for you.
> Modern IDEs will show you the type of anything at all times. I do not understand your point unless you're doing raw text editing of Java source.
The word "String" "Integer" et al. + "var" is too much real estate for being explicit. Sometimes, I'm looking at the decompiled source from some library that doesn't have a source package available.
> Those keystrokes are not just saved on writing, they make the whole code more legible and easier to mentally parse.
This is incorrect. Repeating it doesn't make it true. For trivial code (<10 lines) probably seems fine at the time. Lots of bad practices start with laziness.
Changing practice because an author thinks a function is small enough when it was written, is a recipe for unclean code with no clear guidelines on what to use or expect. Maybe they rather put the onus on a future reader; this is also bad practice.
Previously (or if you simply don't use var), a lot of java code takes the form of
This is just straight up a duplicate. With generics, generic parameters can be left out on one side but the class itself is still duplicated.