7

var is not very handful when you're navigating through the code and investigating the code which is not clear at the first look.

When developers use not self-describing methods names you have to spend some time to understand what is real type of the variable. And if you use Lombok's var you will be tightly coupled with Lombok, so I do not use it very often in my code.

What are the useful use cases for using var in Java?

informatik01
  • 16,038
  • 10
  • 74
  • 104
JavaDev
  • 125
  • 1
  • 4
  • 1
    When developers use unhelpful names, there is not much that will work. Many languages things are made available mostly for the people who name things like they should be. var is a nice fresh breeze over `List` and what else is a variable "dates" going to be, in the context where what you need to deal with is an ordered sequence of dates? – kumesana Aug 06 '19 at 13:16
  • 1
    Java 10 added the var keyword to the language, so the usage is likely to only increase. It is mostly just a way to decrease the verbosity and redundancy of having to specify the type. That said, it can make things a bit more unclear when reading the code. I suspect that best practices will develop around it as it is used more. – Matt Berteaux Aug 06 '19 at 13:26
  • 2
    "if you use lombok's var you will be tightly coupled with lombok" Lombok ships with delombok, a tool which strips out all Lombok usage. So no, you code will not be tightly coupled to Lombok. You can remove it whenever you want. – Michael Aug 06 '19 at 13:26
  • 2
    It's most useful when you are using the `new` operator. `List foo = new ArrayList<>()` becomes `var foo = new ArrayList()`. The type is unambiguous but Java's classic syntax requires that I repeat myself. When using `var`, I don't have to. – Michael Aug 06 '19 at 13:32

1 Answers1

12

Arguments in favor of var:

  • var requires less typing. It's shorter and sometimes easier to read than let's say Map<Integer, ArrayList<String>>.
  • var requires less code changes if a return-type of a method call changes. You only have to change the method call, but not every place it's used.
  • var encourages a more descriptive name for variables. I.e. var customer = new Customer(); rather than var c = new Customer();.
  • When you have multiple variable under one another of different types, the names all line up if they're all var, which wouldn't be the case with the types itself (unless the types coincidentally all have the same length).

Arguments against var:

  • var obscures the actual variable type. If the initializer doesn't return a clearly defined type, you may not be able to tell a variable's type.
  • Using var is lazy. Although var is certainly easier to type than Map<Integer, ArrayList<String>>, if the variable name isn't named well, you'd have to search a lot deeper in order to know what it refers to.
  • var makes it harder to know what the type of the underlying variable actually is.
  • You can't use var in all cases. Like:
    • var i = 1, j = 2; - Only one variable is accepted for var at a time.
    • var arr = {1, 2, 3}; - Arrays must be explicitly declared.
    • var f = a -> a + " "; - It cannot determine what type this lambda function is.
    • var f = String::replace; - Method references cannot be used, because they don't have a type of itself. More info here.

Most of these are taken from this post for when to use var in .NET C#, where the var keyword has been present since the beginning, whereas with Java it's only available since version 10.

Oh, and another big advantage of var: it's shorter for code-golfing (creating a program/function which does a certain task/challenge with as few bytes as possible). :) Probably the main reason why I don't mind that it was added, since I codegolf in Java (as well as .NET C#, 05AB1E, and Whitespace) pretty often.

Related: Java 7's diamond operator. List<String> names = new ArrayList<>(); vs List<String> names = new ArrayList<String>();.

Personally I still use written out types instead of var, except for code-golfing. But maybe I just need to get used to it a bit more before using it more often. For readability, and making it clearer and easier to see the type without having to dig, I don't use var at all. As for Java 7's diamond operator, I only use it when I instantiate it directly after the field, but would not when I instantiate it elsewhere (i.e. I would use List<String> names = new ArrayList<>();, but not List<String> names; /* ... some code here ...*/ names = new ArrayList<>();).
In general it all comes down to preference, though.

Kevin Cruijssen
  • 9,153
  • 9
  • 61
  • 135
  • 5
    I agree. My rule of thumb is to only use `var` in conjunction with `new`. In any other situation, it introduces ambiguity which I'd rather avoid. – Michael Aug 06 '19 at 13:33
  • @Michael Yeah, that's how I also felt about the diamond operator of Java 7, as I mentioned at the bottom. Our applications at work are currently still in Java 8, so I haven't had to work with `var` in a developer situation yet, but I can indeed see it being used at some direct initialization of variables. [It's also mentioned at the bottom of the C# .NET page I linked (section "_How I Use `var` and Suggest You Do As Well_").](https://intellitect.com/when-to-use-and-not-use-var-in-c/). – Kevin Cruijssen Aug 06 '19 at 13:36
  • @KevinCruijssen you can actually use `var` when declaring any class with diamond operator, you have to only declare type on the right side, `var names = new ArrayList();` – Dawid Jan 06 '23 at 09:08