Si je regarde le code source de source Java dans OpenJDK ou Hibernate ou Apache, je n'ai pas encore vu de variables locales déclarées finale.
Cela suggère que les développeurs de certaines des bibliothèques logicielles Java les plus largement utilisées:
ne croyez pas que le dernier mot-clé améliore la lecture de la lecture.
ne croyez pas que cela améliore considérablement la performance.
Pourquoi la majorité des contrecoups sur Stackoverflow croient-il qu'elle devrait être utilisée (sur la base des réponses votées les plus élevées)?
5 Réponses :
Probablement parce que c'est un problème de taper dans les cinq longues lettres dans le mot quand C'est deux fois plus de taper que ? Nous développeurs sont paresseux, vous savez ...: P finale ... Pourquoi passeraient-ils la douleur de l'écriture
C'est définitivement vrai. ; P et finale peuvent être automatiquement ajoutés aux paramètres de la méthode par IDes, ce qui n'est pas si facile pour les variables locales.
Si l'éditeur peut vous dire que cela pourrait être définitif - et il peut également: le compilateur peut également déterminer une variable finale. Il pourrait donc optimiser de manière à ce qu'il n'y ait pas performance bénéfice pour déclarer explicitement final. Cela ne traite pas de la question de la lisibilité.
La question n'était pas de savoir si une IDE peut facilement ajouter le mot-clé, c'est pourquoi les projets mentionnés (OpenJDK, Hibernate, Apache) semblent avoir des normes de codage ou des comités qui choisissent avec soin de ne pas l'utiliser!
@ user695654 Les fonctionnalités utilisées dans une langue sont plutôt liées à Quelle est facile de telles fonctionnalités sont à utiliser. Dans Scala, par exemple, en utilisant Val ("final") a la même "complexité" que "code> var (arguments par défaut sur val ). La raison évidente est que les mots-clés ont la même longueur. Une raison moins évidente, mais tout aussi importante: le code Scala est (idiomatiquement) écrit dans un "style fonctionnel" - qui est autorisé par la syntaxe - qui peut minimiser les effets secondaires (beaucoup moins besoin de "muter" valeurs) et de laisser le Valeurs "écoulement" des structures de contrôle. C'est (tout malheureusement, imoho) pas le cas avec Java.
@pst Oui, je pense que la référence à Scala est pertinente (ish). Peut-être que j'aurais dû rehaîner la question à «Devrions-nous adopter les mêmes normes de codage implicites dans des projets populaires open source?
@Thomas Ce n'est pas le cas, les IDes peuvent faire face à la définition des variables locales finales correctement.
@Tnem Oui, ils peuvent le faire, mais je dirais que ce n'est pas toujours facile de savoir si la variable doit être définitive, par exemple si vous êtes en train de développer une méthode incrémentalement développée et si vous activez / commettre le IDE ajouterait le mot-clé final , vous devrez peut-être le supprimer à nouveau. Pour les paramètres, il est généralement plus facile de configurer une règle comme «les paramètres sont toujours définitifs» afin d'appliquer un style de codage.
Le mot clé final a deux utilisations:
Case 2 est normalement appliqué aux variables de l'élément afin de rendre l'objet immuable (au moins partiellement) ou aux paramètres de la méthode afin d'empêcher les assignations accidentelles.
Dans le cas d'une variable locale (méthode c.-à-d. Méthode Scoped et non un paramètre), cela n'est normalement pas nécessaire ni recherché, car ces variables sont susceptibles d'être modifiées dans la méthode (sinon, vous n'auriez peut-être pas besoin d'eux, sauf cache une référence pour la portée de la méthode).
La question concerne les variables locales et ne pose pas la question théorique sur la manière d'utiliser le mot clé final, mais spécifiquement, il demande pourquoi des projets open source sont constitués du code qui n'utilise pas le mot clé final.
Comme déjà dit, les programmeurs sont paresseux et pourquoi utiliser un mot-clé sur les variables locales qui fournit peu d'avantages le cas échéant? Pour les paramètres ou les membres de la classe finale, c'est bien, mais pour les variables locales, il a peu d'usage pratique.
Ils peuvent être paresseux mais à en juger par la qualité de leurs logiciels, nous pourrions penser à eux comme bon. Donc, ma question est, devrions-nous suivre leur exemple?
'Devrions-nous suivre leur exemple? - Cela dépend du style de codage. Outre le "Ce ne sera plus jamais changé lors de cette exécution d'une méthode" finale a peu d'utilisation. Si la lisibilité vous préoccupe, j'irais d'abord pour d'autres options, comme vous l'avez déjà suggéré. ... Oh, et je dirais que les meilleurs programmeurs sont des programmeurs paresseux, car ils ont souvent tendance à garder des choses simples mais réutilisables (et d'utiliser des bibliothèques bien testées, le cas échéant, au lieu de rouler leur propre code).
Je suis vraiment d'accord avec votre justification de la raison pour laquelle les programmeurs paresseux sont généralement les meilleurs programmeurs.
Je doute de la déclaration d'une variable locale Maintenant que cela améliore parfois la lisibilité, c'est plus subjectif. Dans un morceau de code compliqué, il peut être agréable de promettre (à vous-même ou aux futurs lecteurs) qu'une variable n'est écrite qu'une seule fois. Mais il pourrait être plus agréable de simplifier le code afin que ce soit facilement apparent de toute façon. finale améliore jamais les performances. En vertu de l'existence de final , les compilateurs Java sont déjà nécessaires pour pouvoir indiquer si une variable peut être attribuée plus d'une fois ou pourrait ne pas être initialisée. Par conséquent, déclarant un local comme final ne dis pas au compilateur quoi que ce soit qu'il ne connaissait pas déjà - ce n'est que pour le bénéfice du lecteur.
Aussi loin que je sache, le dernier mot-clé n'a aucun impact sur la performance de vos variables.
Je crois que c'est principal objectif est de vous aider à accrocher des bugs. Si vous savez que quelque chose ne changera jamais, vous le marquez comme tel. Semblable à la raison pour laquelle nous utilisons des annotations où nous pouvons,
Ne croyez pas le mot clé final Améliore la lecture de la lecture.
Certaines personnes (telles que moi) trouvent excessivement
finale s diminue la lisibilité.ne le croyez pas de manière significative Améliore les performances.
final variables locales n'améliore pas les performances.
Related: Stackoverflow.com/questions/316352/...
Related: Stackoverflow.com/Questtions / 137868 / ...
En ce qui concerne la balle de performance, j'ai été amené à croire que cela ne fait aucune différence et que le compilateur le reconnaîtra et optimisera en conséquence. Au mieux, c'est une micro-optimisation et nous savons tous ce que les gens disent à ce sujet! :)
Préférez-vous que la finale «améliore considérablement les performances»? Cela semble indiquer que ce n'est pas le cas: Stackoverflow.com/questions/266806/266981#266981
@ROB: Ouais je le pensais aussi ... Il n'est pas trop difficile pour un compilateur de comprendre une variable n'est jamais affecté dans la plupart des cas. Cela ne devrait donc pas faire la différence.
Vous ne voudrez peut-être pas que les variables locales finales en cas de variables de boucle, des paramètres formels dont les valeurs doivent être ajustées.
@Tim: Non, je ne prétendais pas qu'il améliore considérablement la performance. Comme Rlibby souligne que le compilateur peut déterminer la plupart des améliorations possibles des performances. Peut-être plus significatif est le JVM, il optimise le bytecode et peut choisir un mode d'exécution qu'aucun homme (sain d'esprit) n'aurait pensé!
Sun a publié une norme de convaincre du code il y a plus de 10 ans. Même des suggestions de base et triviales dans la norme, telles que l'utilisation d'espaces au lieu d'onglets, ne sont pas suivies de manière systématique dans une version libérée. Je veux dire trivial car il peut être réparé sur toute la base de code avec une seule commande dans mon IDE.
@ user695654, êtes-vous sûr que
final variables locales produit un code d'octet différent?