[Java] Points à noter sur l'inférence de type étendue dans 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), [Aller](https://ja.wikipedia.org/wiki/Go_(%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 )), [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 Ceux qui développent avec% E8% A8% 80% E8% AA% 9E)) seront familiarisés avec ce que l'on appelle "l'inférence de type". L'inférence de type est une fonction de langage dans les langages à typage statique, et le compilateur détermine automatiquement le type sans décrire explicitement le type, donc comme l'inférence de type de Kotlin,

var a = 1

Juste en écrivant, le compilateur déduira automatiquement du type sur le côté droit que la variable a sur le côté gauche est un type entier. Enfin, même en Java, le fait que "l'inférence de type de variables locales" soit dérivée de Java 10 était un nouvel événement dans ma mémoire.

Par exemple, avant Java 10, il était nécessaire d'écrire explicitement le type de variable comme suit:

String name = "tamito0201";

Dans Java 10, vous pouvez supprimer les types explicites requis dans les déclarations de variables locales en ajoutant le mot-clé var comme suit:

var name = "tamito0201";

Dans le cas ci-dessus, vous ne ressentirez peut-être pas beaucoup d'avantages car String est simplement remplacé par var. Cependant, dans le cas de Java, lorsque vous utilisez l'API de collecte, vous devez écrire du code fastidieusement redondant.

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

Dans Java 10 ou version ultérieure, ce

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

Cela peut être décrit comme. Comme c'est élégant!

Cependant, bien que l'inférence de type soit pratique, c'est aussi une arme à double tranchant qui crée des bogues inattendus. Par conséquent, en fonction du projet, certains projets interdisent la spécification de var par la norme de codage et spécifient explicitement le type. Plus le projet est volumineux, plus le typage explicite à l'ancienne est effectué, compte tenu du risque de créer des bogues inattendus.

Pourquoi? Par exemple, supposons que vous ayez le code suivant:

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

Quelle est la valeur de retour de la fonction getDistance? Ceux qui ont un sens aigu des sentiments ont peut-être remarqué ici. C'est vrai. S'il existe une possibilité de renvoyer l'objet wrapper Integer, null peut être renvoyé. En conséquence, il est évident que nullpo se produira à la prochaine distance * 100, vous devez donc vérifier null.

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

Dans Java 8 ou version ultérieure, vous devez renvoyer Facultatif.

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

En d'autres termes, puisque var est utilisé correctement par le projet ou l'équipe, il est nécessaire de décider de la directive de codage.

--Ne pas utiliser var

• En principe, var est utilisé pour les variables locales. --Utilisez var uniquement si un type explicite est spécifié sur le côté droit --Déterminer le type à spécifier dans la norme de codage et utiliser var sinon --Utilisez var dans votre projet pour couvrir les tests unitaires

Tous sont corrects, mais en réalité 1 ou 2 est considéré comme approprié. Peu importe combien vous spécifiez le type spécifié dans la norme de codage, il est peu probable que tous les ingénieurs se conforment à la norme de codage dans un projet à grande échelle. Déterminé par la norme de codage, Checkstyle, SpotBugs, [PMD](https: // pmd) Je pense qu'il vaut mieux le lier avec .github.io /) etc.

Tout a ses avantages et ses inconvénients.

Assurez-vous de décider quoi faire de ce domaine dans votre projet. Si vous ne décidez pas, la source du projet terminé sera le chaos.