Hacker News Reader

Comment by Supermancho | Hacker News Reader

Can someone explain why developers like var?

Previously (or if you simply don't use var), a lot of java code takes the form of

  BeanFactoryBuilder builder = new BeanFactoryBuilder(...);

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.

It reduces (often repetitive) visual noise in code, which can make it more readable. I wouldn’t recommend using it in all cases, but it’s a good tool to have.

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();

doesn't tell me anything.

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.

Yes, well expressed. For that case using var is not a wise approach.

It does help when writing:

    var x = new MyClass();

Because then you avoid repetition. Anyways, I don't ever use "var" to keep the code compatible with Java-8 style programming and easier on the eyes for the same reasons you mention.

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();

not like

  var myFood = buyFood();

where buyFood has Potato as return type.

2. Even if you don't follow 1, IDEs can show you the type like

  var Potato (in different font/color) myFood = buyFood();

I have the opposite feeling. var makes it easier to write but harder to read/review. Without var you know the exact type of a variable without going through some functions for example

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.

And not only that, Java was like 40 years late to the party. ML had Hindley-Milner type inference back in 1978! I can only imagine how foreign ML must have felt compared to other languages at the time.

I never said Kotlin invented type inference, just that the syntax was straight adopted from kotlin

What syntax? val and var were used by Scala before Kotlin. Lombok also has val. Java just needed to pick a keyword.

It's terse and it lines up the variable names.

It‘s a harmful code smell: It often obfuscates the type, forcing you to actively check for the type and should not be used.

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.

Your IDE can do that?

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.

Languages should not be designed around the assumption that people use an IDE.

What if I'm just looking at a pull request on GitHub? Sure I can check out the branch etc but that's just adding more friction.

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.

If you haven’t used GitHub plugins in your ide to review you should really give it a try. It’s really night and day.

It is used for things like "Foo x = new Foo()" where the type is obvious.

Reply on news.ycombinator.com