Défis dans la cohérence des outils de nommage des méthodes
L'examen des outils actuels pour la cohérence des noms de méthode révèle des lacunes importantes.
― 10 min lire
Table des matières
- L'importance du nommage
- Défis des techniques actuelles
- Rôle des revues de code
- Questions de recherche
- Aperçu de l'étude empirique
- Résultats de l'étude
- Évaluation de la recommandation de noms de méthodes
- Évaluation de la vérification de cohérence des noms de méthodes
- Conclusion
- Source originale
- Liens de référence
Le choix des noms de méthodes dans le code logiciel est super important. Des noms de méthodes clairs facilitent la compréhension du code pour les développeurs et aident à le maintenir au fil du temps. Cependant, les développeurs utilisent parfois des noms qui ne sont pas cohérents à cause d'une mauvaise communication ou de méconnaissance des règles de nommage dans le processus de développement logiciel. Pour remédier à ça, de nombreux chercheurs ont travaillé sur des outils pouvant vérifier automatiquement la cohérence des noms de méthodes et proposer de meilleurs noms. Malheureusement, beaucoup de ces outils n'expliquent pas pourquoi un nom est mauvais, ce qui limite leur aide. Savoir pourquoi les changements de nom sont effectués peut guider des améliorations dans les recommandations de nommage.
Pour combler cette lacune, nous avons créé un benchmark appelé ReName4J, qui relie les changements de noms aux revues de code. Cet article examine à quel point les outils actuels peuvent trouver et suggérer des noms de méthodes cohérents en utilisant ce benchmark. On vise à fournir une perspective nouvelle basée sur des revues de code réelles plutôt que de présenter un nouveau benchmark en soi. Nos résultats montrent que les outils actuels ont du mal à bien fonctionner lorsqu'ils sont confrontés à notre benchmark axé sur la revue. On souligne aussi des biais possibles dans l'évaluation des outils existants, ce qui montre qu'il y a besoin d'un examen plus approfondi dans les recherches futures.
L'importance du nommage
Une méthode dans un logiciel, c'est un petit bout de code qui fait une tâche précise. Choisir des noms de méthodes qui respectent les règles de nommage établies et décrivent clairement ce que fait la méthode est essentiel. Ça aide à rendre le code plus facile à maintenir et à lire. Malgré cela, les développeurs ont souvent du mal à trouver des noms adéquats.
Par exemple, dans certains projets open-source, une méthode nommée register
sous-entend qu'elle sauvegarde des données alors qu'en fait, elle crée et renvoie un nouvel objet. De même, une méthode appelée transitToRestoreActive
donne l'impression de changer sélectivement l'état d'un programme, mais en réalité, elle fonctionne en continu. Les revues de code pour ces méthodes ont suggéré des noms alternatifs comme generateToken
et enforceRestoreActive
, qui reflètent mieux leurs fonctions réelles.
Pour lutter contre le problème des noms de méthodes incohérents, les chercheurs ont proposé des techniques pour automatiser deux tâches principales : vérifier la cohérence des noms de méthodes et recommander de meilleurs noms. Cependant, évaluer ces techniques de manière significative peut être un défi.
Défis des techniques actuelles
De nombreux ensembles de données existants utilisés pour évaluer les outils de nommage sont limités. Par exemple, certains ensembles de données ne comprennent que des révisions qui ne changent que les noms de méthodes, sans insights sur la cohérence de ces changements avec les normes de la communauté ou les opinions personnelles des développeurs. De plus, beaucoup d'ensembles de données sont construits pour s'adapter à des méthodes d'apprentissage spécifiques, ce qui peut ne pas refléter les conditions réelles où les noms de méthodes deviennent stables avec le temps. Ainsi, les outils conçus pour vérifier les problèmes de nommage peuvent avoir des difficultés avec des ensembles de données déséquilibrés où la plupart des noms sont déjà cohérents.
En outre, de nombreuses approches reposent sur des métriques de similarité spécifiques qui ont été adaptées à des ensembles de données uniques, soulevant des questions sur leur application plus large.
Rôle des revues de code
Les revues de code sont essentielles et peuvent fournir des informations précieuses sur les défis de nommage. Des recherches montrent que les noms de méthodes ressortent souvent dans les discussions lors des revues, où les développeurs partagent leurs réflexions sur l'amélioration des noms. Ces discussions peuvent former une base solide pour créer une base de données d'exemples de renommage de méthodes qui peut être utilisée pour évaluer les outils de vérification de cohérence et de recommandations actuels.
Dans notre benchmark, nous avons collecté des revues à partir de demandes de fusion, en nous concentrant sur des termes liés au nommage pour identifier les discussions pertinentes. Nous avons recueilli des patches avec des commentaires, nous permettant d'extraire des noms de méthodes et de compiler un échantillon de 400 paires de noms de méthodes, chacune montrant un changement soutenu par une revue.
Questions de recherche
Avec le benchmark ReName4J, on vise à répondre à plusieurs questions de recherche critiques :
- Les outils existants peuvent-ils retrouver les bons noms pour les méthodes qui apparaissent dans les scénarios de Revue de code ?
- Ces outils identifient-ils efficacement les noms de méthodes cohérents et incohérents ?
- Que se passe-t-il lorsque nous testons ces outils sur un ensemble de données qui ressemble à de réelles pratiques logicielles, par opposition à des ensembles de données soigneusement équilibrés ?
Les réponses à ces questions peuvent aider à combler le fossé entre la recherche et la pratique dans le développement logiciel, en se concentrant spécifiquement sur la cohérence et la recommandation des noms de méthodes.
Aperçu de l'étude empirique
Cette étude comprend trois étapes : construire un benchmark de nommage, réentraîner des outils de recommandation de noms de méthodes existants, et tester leur performance par rapport à notre benchmark. Le benchmark est créé à partir de données de revue de code, assurant que les tâches de renommage de méthodes sont soutenues par des discussions parmi les développeurs.
Pour notre benchmark, nous examinons des paires de noms de méthodes pour vérifier l'incohérence et recommander de meilleurs noms. L'étude évalue trois techniques modernes : Spot, Cognac, et GTNM, en se concentrant sur leur capacité à réaliser les deux tâches mentionnées.
Collecte de données
Pour collecter des données, nous nous sommes concentrés sur les meilleurs projets Java de GitHub. Pour créer un ensemble de données robuste et pertinent, nous avons écarté les projets qui n'étaient pas principalement en anglais et avons restreint notre recherche à des projets ayant des discussions significatives sur les noms de méthodes. En utilisant l'API REST de GitHub, nous avons recueilli des demandes de fusion et identifié des revues pertinentes basées sur des mots-clés liés au nommage.
Ce processus nous a permis de collecter une multitude de données sur les tâches de renommage de méthodes liées aux commentaires de revues de code, contribuant à la création de notre benchmark pratique.
Résultats de l'étude
Les résultats de notre étude révèlent plusieurs problèmes avec les techniques de nommage actuelles lorsqu'elles sont appliquées à notre benchmark :
- Les outils échouent souvent à recommander des noms appropriés pour les méthodes, obtenant de moins bons résultats sur nos données de nommage par rapport à leurs évaluations précédentes.
- Lorsqu'ils tentent de vérifier la cohérence, ces outils classent mal de nombreux noms, indiquant une baisse significative de leur précision.
Problèmes avec les techniques actuelles
Dans l'ensemble, les techniques actuelles montrent une tendance à favoriser des noms de méthodes courts et simples alors que les revues de code indiquent que les développeurs préfèrent des noms détaillés et descriptifs. Par exemple, la longueur moyenne des noms de méthodes dans les modèles existants est significativement plus courte que celle de notre benchmark, montrant une différence claire dans les préférences de nommage.
Lors de l'évaluation des outils, nous avons constaté qu'ils avaient du mal avec les noms plus complexes présents dans notre ensemble de données, qui contiennent plus d'informations sur les méthodes.
Évaluation de la recommandation de noms de méthodes
La première tâche de notre étude consiste à évaluer l'efficacité des techniques ciblées à recommander des noms de méthodes pour des corps de méthodes spécifiques. Cette tâche implique d'analyser à quel point chaque outil peut fournir le bon nom de méthode à partir des benchmarks que nous avons recueillis.
Nous avons observé que les techniques ont constamment affiché de mauvais résultats sur notre ensemble de données par rapport à leurs évaluations antérieures. Revoir les raisons derrière les recommandations des outils a mis en évidence la nécessité de prendre en compte un contexte plus large.
Par exemple, dans certains cas, les techniques ont recommandé un nom qui ne parvenait pas à saisir l'objectif unique de la méthode en raison d'un manque de connaissances contextuelles, suggérant que les outils actuels doivent améliorer leur compréhension de la structure générale du code.
Évaluation de la vérification de cohérence des noms de méthodes
La deuxième tâche consiste à vérifier si chaque technique peut classer correctement les noms de méthodes comme cohérents ou incohérents. L'attente est que les outils devraient être capables d'identifier les noms qui ne s'alignent pas avec leurs corps de méthode respectifs.
Dans cette partie de l'étude, nous avons remarqué qu'il y avait de nombreux cas où les outils classaient à tort des noms, en particulier avec des méthodes existantes qui étaient présumées stables. La tendance des outils à classer la plupart des noms comme incohérents nous a amenés à remettre en question l'efficacité de leurs algorithmes.
Ensembles de données déséquilibrés
Le dernier domaine que nous avons examiné était l'efficacité de ces techniques lorsqu'elles sont testées sur des ensembles de données déséquilibrés qui imitent des situations réelles. Dans ces scénarios, les outils ont rencontré des difficultés à identifier correctement la majorité des noms cohérents et ont plutôt classé beaucoup comme incohérents.
Les résultats indiquent que les outils peuvent avoir des seuils ou des paramètres trop stricts, entraînant des taux de classification erronée élevés. Ajuster les seuils pourrait aider à améliorer leur performance.
Conclusion
Cette étude met en lumière les défis auxquels sont confrontées les techniques actuelles de vérification de cohérence et de recommandation de noms de méthodes lorsqu'elles sont confrontées à des données réelles. Nous avons constaté que beaucoup d'outils luttent avec précision et efficacité, en particulier lors de l'évaluation de tâches de nommage complexes basées sur des données de revues de code.
À l'avenir, il sera essentiel que les chercheurs et les développeurs se concentrent sur le perfectionnement de ces techniques, en tenant compte des riches informations contextuelles disponibles dans les revues de code. Améliorer les algorithmes utilisés pour les recommandations de noms de méthodes et les vérifications de cohérence pourrait considérablement améliorer la maintenabilité et la lisibilité des logiciels.
Les insights tirés de cette étude peuvent servir de guide pour de futures recherches, menant potentiellement à de meilleures méthodologies qui contribuent positivement au paysage du développement logiciel.
Titre: How are We Detecting Inconsistent Method Names? An Empirical Study from Code Review Perspective
Résumé: Proper naming of methods can make program code easier to understand, and thus enhance software maintainability. Yet, developers may use inconsistent names due to poor communication or a lack of familiarity with conventions within the software development lifecycle. To address this issue, much research effort has been invested into building automatic tools that can check for method name inconsistency and recommend consistent names. However, existing datasets generally do not provide precise details about why a method name was deemed improper and required to be changed. Such information can give useful hints on how to improve the recommendation of adequate method names. Accordingly, we construct a sample method-naming benchmark, ReName4J, by matching name changes with code reviews. We then present an empirical study on how state-of-the-art techniques perform in detecting or recommending consistent and inconsistent method names based on ReName4J. The main purpose of the study is to reveal a different perspective based on reviewed names rather than proposing a complete benchmark. We find that the existing techniques underperform on our review-driven benchmark, both in inconsistent checking and the recommendation. We further identify potential biases in the evaluation of existing techniques, which future research should consider thoroughly.
Auteurs: Kisub Kim, Xin Zhou, Dongsun Kim, Julia Lawall, Kui Liu, Tegawendé F. Bissyandé, Jacques Klein, Jaekwon Lee, David Lo
Dernière mise à jour: 2023-08-24 00:00:00
Langue: English
Source URL: https://arxiv.org/abs/2308.12701
Source PDF: https://arxiv.org/pdf/2308.12701
Licence: https://creativecommons.org/licenses/by-sa/4.0/
Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.
Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.
Liens de référence
- https://github.com/apache/flink/pull/14863
- https://github.com/elastic/elasticsearch/pull/82639
- https://medium.com/transparent-data-eng/good-practices-of-code-review-guide-for
- https://github.com/apache/shardingsphere/pull/18618
- https://github.com/wangpeibin713/flink/blob/748ad82745d9d493922150fe007136e125a50209/flink-table/flink-table-runtime-blink/src/test/java/org/apache/flink/table/runtime/operators/deduplicate/ProcTimeDeduplicateKeepLastRowFunctionTest.java
- https://github.com/open-beagle/shardingsphere/blob/5be6a2c81c647cdffb1f7f17db9c69204be14b4e/shardingsphere-proxy/shardingsphere-proxy-backend/src/test/java/org/apache/shardingsphere/proxy/backend/text/distsql/rdl/resource/AlterResourceBackendHandlerTest.java
- https://github.com/dhruvilshah3/kafka/blob/4c882dee7cacc4e09e13dc071804e6a1d8c8aaac/clients/src/main/java/org/apache/kafka/common/network/KafkaChannel.java
- https://github.com/Apache/eat-kafka/blob/a268e35e3c204b4335a19483b8ec3703c4d97e39/kafka-2.4.0-src/streams/src/test/java/org/apache/kafka/streams/state/internals/metrics/RocksDBMetricsRecorderTest.java
- https://github.com/apache/kafka/pull/2282
- https://github.com/apache/kafka/pull/1486
- https://github.com/apache/kafka/pull/11689
- https://figshare.com/s/8cdb4e3208e01991e45c
- https://docs.github.com/en/rest
- https://github.com/apache/kafka/pull/8988
- https://github.com/jenkinsci/jenkins/pull/4239
- https://github.com/jenkinsci/jenkins/pull/4239/files/41919ee7829223062d5d5ca4d592fd8056e55017#r330954855
- https://github.com/apache/kafka/pull/8319/files/c7ac051e495a98b6c72a340c24f4b9bb1f25dcdd#r395348873
- https://github.com/jenkinsci/jenkins/pull/4239/files/41919ee7829223062d5d5ca4d592fd8056e55017
- https://github.com/apache/kafka/pull/8319/
- https://github.com/apache/kafka/pull/8319/files/c7ac051e495a98b6c72a340c24f4b9bb1f25dcdd
- https://openreview.net/forum?id=H1gKYo09tX
- https://doi.org/10.1109/ICSE43902.2021.00061
- https://github.com/
- https://www.nndb.com/people/400/000031307/
- https://doi.org/10.1109/APSEC53868.2021.00010
- https://doi.org/10.1145/3510003.3510154