Desafíos en las herramientas de consistencia de nombres de métodos
Al revisar las herramientas actuales para la consistencia en los nombres de método, se notan fallos importantes.
― 9 minilectura
Tabla de contenidos
- La Importancia del Nombrado
- Desafíos en las Técnicas Actuales
- Rol de las Revisiones de Código
- Preguntas de Investigación
- Resumen del Estudio Empírico
- Hallazgos del Estudio
- Evaluación de la Recomendación de Nombres de Métodos
- Evaluación de la Verificación de Consistencia de Nombres de Métodos
- Conclusión
- Fuente original
- Enlaces de referencia
Nombrar bien los métodos en el código de software es clave. Nombres claros hacen que sea más fácil para los desarrolladores entender el código y mantenerlo a lo largo del tiempo. Sin embargo, a veces los desarrolladores usan nombres que no son coherentes por problemas de comunicación o porque no conocen las reglas de nombrado en el proceso de desarrollo de software. Para solucionar esto, muchos investigadores han trabajado en crear herramientas que puedan comprobar automáticamente la consistencia de los nombres de los métodos y sugerir mejores nombres. Lamentablemente, muchas de estas herramientas no explican por qué un nombre está mal, lo que limita su utilidad. Conocer las razones detrás de los cambios de nombre puede guiar mejoras en las recomendaciones de nombrado.
Para llenar este vacío, hemos creado un benchmark llamado ReName4J, que conecta los cambios de nombre con las revisiones de código. Este artículo examina qué tan bien pueden encontrar y sugerir nombres de métodos consistentes las herramientas actuales utilizando este benchmark. Nuestro objetivo es proporcionar una nueva perspectiva basada en revisiones de código reales en lugar de presentar un nuevo benchmark en sí. Nuestros hallazgos indican que las herramientas actuales tienen problemas para funcionar bien cuando se evalúan con nuestro benchmark enfocado en revisiones. También señalamos posibles sesgos en la forma en que se evalúan las herramientas existentes, destacando la necesidad de un examen más profundo en futuras investigaciones.
La Importancia del Nombrado
Un método en software es un pequeño fragmento de código que realiza una tarea específica. Es esencial elegir nombres de métodos que se alineen con las reglas de nombrado establecidas y describan claramente lo que hace el método. Esto ayuda a que el código sea más mantenible y fácil de leer. A pesar de esto, a los desarrolladores a menudo les cuesta encontrar nombres adecuados.
Por ejemplo, en algunos proyectos de código abierto, un método llamado register
sugiere que guarda datos, mientras que en realidad crea y devuelve un nuevo objeto. De manera similar, un método llamado transitToRestoreActive
da la impresión de cambiar selectivamente el estado de un programa, pero el método se ejecuta continuamente. Las revisiones de código para estos métodos sugirieron nombres alternativos como generateToken
y enforceRestoreActive
, que reflejan mejor sus funciones reales.
Para combatir el problema de los nombres de métodos inconsistentes, los investigadores han propuesto técnicas para automatizar dos tareas principales: comprobar la consistencia en los nombres de métodos y recomendar mejores nombres. Sin embargo, evaluar estas técnicas de manera significativa puede ser un desafío.
Desafíos en las Técnicas Actuales
Muchos de los conjuntos de datos existentes utilizados para evaluar herramientas de nombrado son limitados. Por ejemplo, algunos conjuntos de datos consisten en revisiones que solo cambian nombres de métodos sin información sobre si esos cambios fueron consistentes con los estándares de la comunidad o la opinión personal del desarrollador. Además, muchos conjuntos de datos están diseñados para ajustarse a métodos de aprendizaje específicos, lo que puede no reflejar condiciones del mundo real donde los nombres de los métodos se estabilizan con el tiempo. Así, las herramientas diseñadas para comprobar problemas de nombrado pueden tener dificultades con conjuntos de datos desbalanceados donde la mayoría de los nombres ya son consistentes.
También, muchos enfoques dependen de métricas de similitud específicas que han sido adaptadas para conjuntos de datos individuales, lo que plantea preguntas sobre su aplicación más amplia.
Rol de las Revisiones de Código
Las revisiones de código son esenciales y pueden proporcionar información valiosa sobre los desafíos de nombrado. La investigación muestra que los nombres de métodos a menudo surgen en discusiones durante las revisiones, donde los desarrolladores comparten ideas sobre cómo mejorar los nombres. Estas discusiones pueden formar una base sólida para crear una base de datos de instancias de cambio de nombre de métodos que pueden usarse para evaluar las herramientas de revisión de consistencia de nombres actuales y las recomendaciones.
En nuestro benchmark, recopilamos revisiones de pull requests, enfocándonos en términos relacionados con el nombrado para identificar discusiones relevantes. Reunimos parches junto con comentarios, lo que nos permitió extraer nombres de métodos y compilar una muestra de 400 pares de nombres de métodos, cada uno demostrando un cambio respaldado por una revisión.
Preguntas de Investigación
Usando el benchmark ReName4J, buscamos responder varias preguntas de investigación críticas:
- ¿Pueden las herramientas existentes recuperar los nombres correctos para los métodos que aparecen en escenarios de Revisión de Código?
- ¿Estas herramientas detectan efectivamente nombres de métodos consistentes e inconsistentes?
- ¿Qué sucede cuando probamos estas herramientas en un conjunto de datos que se asemeja a las prácticas de software del mundo real en lugar de conjuntos de datos cuidadosamente balanceados?
Las respuestas a estas preguntas pueden ayudar a cerrar la brecha entre la investigación y la práctica en el desarrollo de software, centrándose específicamente en la consistencia y recomendación de nombres de métodos.
Resumen del Estudio Empírico
Este estudio implica tres pasos: construir un benchmark de nombrado, volver a entrenar herramientas existentes de recomendación de nombres de métodos, y probar su rendimiento contra nuestro benchmark. El benchmark se crea a partir de datos de revisión de código, asegurando que las tareas de cambio de nombre de métodos estén respaldadas por discusiones entre desarrolladores.
Para nuestro benchmark, examinamos pares de nombres de métodos para verificar la inconsistencia y recomendar mejores nombres. El estudio evalúa tres técnicas modernas-Spot, Cognac y GTNM-enfocándose en su capacidad para realizar las dos tareas mencionadas.
Recolección de Datos
Al recopilar datos, nos enfocamos en los principales proyectos de Java de GitHub. Para crear un conjunto de datos robusto y relevante, descartamos proyectos que no estaban principalmente en inglés y limitamos nuestra investigación a proyectos con discusiones significativas sobre nombres de métodos. Usando la API REST de GitHub, recopilamos pull requests e identificamos revisiones relevantes basadas en palabras clave relacionadas con el nombrado.
Este proceso nos permitió recopilar una gran cantidad de datos sobre tareas de cambio de nombre de métodos vinculadas a los comentarios de la revisión de código, contribuyendo a la creación de nuestro benchmark práctico.
Hallazgos del Estudio
Los hallazgos de nuestro estudio revelan varios problemas con las técnicas actuales de nombrado cuando se aplican a nuestro benchmark:
- Las herramientas a menudo no logran recomendar nombres adecuados para los métodos, teniendo un rendimiento peor en nuestros datos de nombrado en comparación con sus evaluaciones anteriores.
- Al intentar comprobar la consistencia, estas herramientas clasifican mal muchos nombres, indicando una caída significativa en su precisión.
Problemas con las Técnicas Actuales
En general, las técnicas actuales muestran una tendencia a favorecer nombres de método más cortos y simples, mientras que las revisiones de código indican que los desarrolladores prefieren nombres detallados y descriptivos. Por ejemplo, la longitud promedio de los nombres de métodos en modelos existentes es significativamente más corta que la de nuestro benchmark, demostrando una clara diferencia en las preferencias de nombrado.
Cuando evaluamos las herramientas, encontramos que tenían problemas con los nombres más complejos presentes en nuestro conjunto de datos, que contienen más información sobre los métodos.
Evaluación de la Recomendación de Nombres de Métodos
La primera tarea de nuestro estudio es evaluar la efectividad de las técnicas objetivo en recomendar nombres de métodos para cuerpos de métodos específicos. Esta tarea implica analizar qué tan bien cada herramienta puede proporcionar el nombre de método correcto de los benchmarks que recopilamos.
Observamos que las técnicas consistentemente tuvieron un rendimiento pobre en nuestro conjunto de datos en comparación con sus evaluaciones anteriores. Revisar la razón detrás de las recomendaciones de las herramientas destacó la necesidad de considerar un contexto más amplio.
Por ejemplo, en algunos casos, las técnicas recomendaron un nombre que no logró capturar el propósito único del método debido a la falta de conocimiento contextual, sugiriendo que las herramientas actuales necesitan mejorar su comprensión de la estructura general del código.
Evaluación de la Verificación de Consistencia de Nombres de Métodos
La segunda tarea se centra en comprobar si cada técnica puede clasificar con precisión los nombres de métodos como consistentes o inconsistentes. La expectativa es que las herramientas deberían ser capaces de identificar nombres que no se alinean con sus respectivos cuerpos de método.
En esta parte del estudio, notamos que hubo muchos casos donde las herramientas clasificaron erróneamente los nombres, particularmente con métodos existentes que se suponía eran estables. La tendencia de las herramientas a clasificar la mayoría de los nombres como inconsistentes nos llevó a cuestionar la efectividad de sus algoritmos.
Conjuntos de Datos Desbalanceados
El último área que investigamos fue la efectividad de estas técnicas cuando se probaron en conjuntos de datos desbalanceados que imitan situaciones del mundo real. En estos escenarios, las herramientas tuvieron dificultades para identificar con precisión la mayoría de los nombres consistentes y en su lugar clasificaron muchos como inconsistentes.
Los resultados indican que las herramientas pueden tener umbrales o parámetros demasiado estrictos, lo que lleva a altas tasas de clasificación errónea. Ajustar los umbrales podría ayudar a mejorar su rendimiento.
Conclusión
Este estudio destaca los desafíos que enfrentan las técnicas actuales de verificación de consistencia de nombres de métodos y recomendaciones cuando se confrontan con datos del mundo real. Encontramos que muchas de las herramientas tienen problemas de precisión y efectividad, especialmente cuando evalúan tareas de nombrado complejas basadas en datos de revisión de código.
De cara al futuro, será esencial que investigadores y desarrolladores se centren en refinar estas técnicas, teniendo en cuenta la rica información contextual disponible en las revisiones de código. Mejorar los algoritmos utilizados para las recomendaciones de nombres de métodos y las verificaciones de consistencia podría mejorar significativamente la mantenibilidad y legibilidad del software.
Los conocimientos obtenidos de este estudio pueden servir como guía para futuras investigaciones, potencialmente llevando a mejores metodologías que contribuyan positivamente al panorama del desarrollo de software.
Título: How are We Detecting Inconsistent Method Names? An Empirical Study from Code Review Perspective
Resumen: 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.
Autores: Kisub Kim, Xin Zhou, Dongsun Kim, Julia Lawall, Kui Liu, Tegawendé F. Bissyandé, Jacques Klein, Jaekwon Lee, David Lo
Última actualización: 2023-08-24 00:00:00
Idioma: English
Fuente URL: https://arxiv.org/abs/2308.12701
Fuente PDF: https://arxiv.org/pdf/2308.12701
Licencia: https://creativecommons.org/licenses/by-sa/4.0/
Cambios: Este resumen se ha elaborado con la ayuda de AI y puede contener imprecisiones. Para obtener información precisa, consulte los documentos originales enlazados aquí.
Gracias a arxiv por el uso de su interoperabilidad de acceso abierto.
Enlaces de referencia
- 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