car ce n'est ni plus substantiellement long à écrire, ni à lire, ni à comprendre, ni à stocker.
Donc, pour moi, à ce niveau, 'var' c'est inutile.
Le gain principal c'est qu'il n'y a pas de répétition, ça fait moins d'information à lire / à analyser. C'est pas énorme, mais on n'a jamais dit que ça révolutionnait le monde.
2
Désolé si ce n'était pas clair dans mon commentaire précédent, mais je n'ai jamais dit que c'était bien de mettre des var partout. Je dis juste qu'il y a des fois, c'est ce que fait le code qui est important, pas comment il le fait. Ce n'est clairement pas le cas de tous les codes.
le problème est masqué car le var myContacts = getContacts(); est juste au dessus de ta boucle.
Intercales un ou deux écrans de code et tu n'a plus le contexte.
Je ne vois pas ce qu'un écran ou deux changeraient. Au pire, tu ne sais plus que ça n'a pas été initialisé avec la méthode getContacts() mais ça n'a aucun rapport avec le typage.
Pour pas te perdre, tu vas avoir tendance à généraliser ce que tu fais dans ton exemple, cad nommer tes variables en fonction de leurs types.
Mes variables sont nommées en fonction de ce qu'elles contiennent, pas en fonction du type. Qu'est-ce qui te fait dire ça ?
Peut être un exemple simple et court qui te parleras plus :
On est d'accord dans ton exemple, l'implémentation sous-jacente est importante, c'est donc un cas où il ne faut pas utiliser var.
Pour le formuler autrement : développer c'est empiler des abstractions les une au dessus des autres. Le but c'est de choisir le niveau d'abstraction qui te permet d'être le plus efficace. Et ce n'est pas le niveau qui donne le plus d'information qui est le meilleur (sinon on serait tous en train de faire de la mécanique quantique pour comprendre notre code), c'est celui qui donne l'information la plus pertinente. Et ça ça dépend du contexte. Par exemple, je reprends ma variable contacts.
Si tu as besoin de trier une liste de contacts avec de grosses contraintes de performances, tu as intérêt à savoir précisément le type mais aussi à avoir des statistiques sur le contenu et le contexte d'appel. Tu as besoin de beaucoup d'informations. Tu vas écrire ta fonction avec un typage explicite et pas mal de commentaires pour documenter tout ce que le langage ne te permet pas d'écrire formellement.
Si tu as besoin d'afficher le nom de chaque contact, tu te moques de tout ça, tu ne le précises pas. Et si tu devais lire une telle fonction mais avec toutes ces informations, tu insulterais certainement le développeur qui te fait perdre ton temps avec des détails inutiles. Le type est juste un de ces détails inutiles parmi d'autres. La différence c'est que c'est une information apportée par le langage, non par les commentaires et que jusqu'à cette version il n'y avait donc aucun moyen de dire "le type de cette variable, c'est pas ce qu'il y a de plus important pour comprendre le code".
[^] # Re: Inférence de types
Posté par NicolasP . En réponse à la dépêche Sortie de JDK 10. Évalué à 2.
1
Le gain principal c'est qu'il n'y a pas de répétition, ça fait moins d'information à lire / à analyser. C'est pas énorme, mais on n'a jamais dit que ça révolutionnait le monde.
2
Désolé si ce n'était pas clair dans mon commentaire précédent, mais je n'ai jamais dit que c'était bien de mettre des var partout. Je dis juste qu'il y a des fois, c'est ce que fait le code qui est important, pas comment il le fait. Ce n'est clairement pas le cas de tous les codes.
Je ne vois pas ce qu'un écran ou deux changeraient. Au pire, tu ne sais plus que ça n'a pas été initialisé avec la méthode getContacts() mais ça n'a aucun rapport avec le typage.
Mes variables sont nommées en fonction de ce qu'elles contiennent, pas en fonction du type. Qu'est-ce qui te fait dire ça ?
On est d'accord dans ton exemple, l'implémentation sous-jacente est importante, c'est donc un cas où il ne faut pas utiliser var.
Pour le formuler autrement : développer c'est empiler des abstractions les une au dessus des autres. Le but c'est de choisir le niveau d'abstraction qui te permet d'être le plus efficace. Et ce n'est pas le niveau qui donne le plus d'information qui est le meilleur (sinon on serait tous en train de faire de la mécanique quantique pour comprendre notre code), c'est celui qui donne l'information la plus pertinente. Et ça ça dépend du contexte. Par exemple, je reprends ma variable contacts.
Si tu as besoin de trier une liste de contacts avec de grosses contraintes de performances, tu as intérêt à savoir précisément le type mais aussi à avoir des statistiques sur le contenu et le contexte d'appel. Tu as besoin de beaucoup d'informations. Tu vas écrire ta fonction avec un typage explicite et pas mal de commentaires pour documenter tout ce que le langage ne te permet pas d'écrire formellement.
Si tu as besoin d'afficher le nom de chaque contact, tu te moques de tout ça, tu ne le précises pas. Et si tu devais lire une telle fonction mais avec toutes ces informations, tu insulterais certainement le développeur qui te fait perdre ton temps avec des détails inutiles. Le type est juste un de ces détails inutiles parmi d'autres. La différence c'est que c'est une information apportée par le langage, non par les commentaires et que jusqu'à cette version il n'y avait donc aucun moyen de dire "le type de cette variable, c'est pas ce qu'il y a de plus important pour comprendre le code".