[Java] Things to note about type inference extended in Java 10

[Swift](https://ja.wikipedia.org/wiki/Swift_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3 % 83% B3% E3% 82% B0% E8% A8% 80% E8% AA% 9E)), Scala, [Kotlin](https:: //ja.wikipedia.org/wiki/Kotlin), Go % E3% 83% A9% E3% 83% 9F% E3% 83% B3% E3% 82% B0% E8% A8% 80% E8% AA% 9E )), [Rust](https: // ja. wikipedia.org/wiki/Rust_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0 Those who are developing with% E8% A8% 80% E8% AA% 9E)) will be familiar with so-called "type inference". Type inference is a language function in statically typed languages, and the compiler automatically determines the type without explicitly describing the type, so like Kotlin's type inference,

var a = 1

Just by writing, the compiler will automatically infer from the type on the right side that the variable a on the left side is an integer type. Finally, in Java, the fact that "type inference of local variables" was derived from Java 10 was also a new event in my memory.

For example, prior to Java 10, it was necessary to explicitly write the variable type as follows:

String name = "tamito0201";

In Java 10, you can remove the required explicit types in local variable declarations by adding the var keyword as follows:

var name = "tamito0201";

In the above case, you may not feel much benefit because String has just been replaced by var. However, in the case of Java, when using the collection API, you have to write tediously verbose code.

HashMap<Integer, String> map = new HashMap<Integer, String>();

In Java 10 or later, this

var map = new HashMap<Integer, String>();

It can be described as. How elegant it is!

However, while type inference is convenient, it is also a double-edged sword that creates unexpected bugs. Therefore, depending on the project, there are some projects that prohibit the specification of var by the coding standard and explicitly specify the type. The larger the project, the more often the old-fashioned explicit typing is done, considering the risk of creating unexpected bugs.

why? For example, suppose you have the following code:

var distance = getDistance();
System.out.println(distance * 100);

What is the return value of the getDistance function? Those who have a keen sense of feeling may have noticed here. That's right. If there is a possibility of returning an Integer that is a wrapper object, null may be returned. As a result, it is obvious that a nullpo will occur at the next distance * 100, so you need to check null.

Integer distance = getDistance();
if (distance != null) {
    System.out.println(distance * 100);
}

In Java 8 or later, you should return Optional.

Optional<Integer> distance = Optional.ofNullable(getDistance());
distance.ifPresent(d -> System.out.println(d * 100));

In other words, since var is used properly for the project or team, it is necessary to decide the coding guideline.

--Do not use var --In principle, var is used for local variables. --Use var only if an explicit type is specified on the right side --Determine the type to be specified in the coding standard and use var otherwise --Use var in your project to cover with unit tests

All of them are correct, but in reality, 1 or 2 is considered to be appropriate. No matter how much you specify the type specified in the coding standard, it is unlikely that all engineers will comply with the coding standard in a large-scale project. Determined by the coding standard, Checkstyle, SpotBugs, PMD I think it's better to tie it up with .github.io /) etc.

Everything has its advantages and disadvantages.

Be sure to decide what to do with this area in your project. If you don't decide, the source of the completed project will be chaos.