Large Language Models (LLMs) are currently used for various software development tasks, including generating code snippets to solve specific problems. Unlike reuse from the Web, LLMs are limited in providing provenance information about the generated code, which may have important trustworthiness and legal consequences. While LLM-based assistants may provide external links that are “related” to the generated code, we do not know how relevant such links are. This paper presents the findings of an empirical study assessing the extent to which 243 and 194 code snippets, across six programming languages, generated by Bing CoPilot and Google Gemini, likely originate from the links provided by these two LLM-based assistants. The study leverages automated code similarity assessments with thorough manual analysis. The study’s findings indicate that the LLM-based assistants provide a mix of relevant and irrelevant links having a different nature. Specifically, although 66% of the links from Bing CoPilot and 28% from Google Gemini are relevant, LLMs-based assistants still suffer from serious “provenance debt”.

Context: Test-Driven Development ( TDD ) is an agile development approach where the writing of unit tests precedes the writing of production code. Some software engineers have been advocating the use of TDD to develop Embedded Systems ( ESs ) despite the lack of empirical evidence on TDD applied to ES development. Objectives: Our overarching objective is to start building knowledge on TDD applied to ES development. Specifically, we investigated: (i) the claimed benefits of TDD ( i.e., increased external quality of ESs and developers’ productivity) and (ii) how developers apply TDD when developing ESs. Method: We conducted two empirical investigations. The former investigation, comprising two experiments, aimed to study the claimed benefits of TDD. To that end, we asked Computer Science (CS) Master’s students to fulfill ES development tasks by using TDD or a non-TDD approach. The latter investigation consisted of an ethnographically-informed study to gain insights into how developers apply TDD when developing ESs. In this study, we involved CS Master’s students, who were observed while fulfilling an ES development task. The participants in the two empirical investigations were different. Results: We found that the external quality of the developed ESs increased when using TDD as compared to a non-TDD approach, while there was not a substantial difference in developers’ productivity. However, TDD is perceived as more difficult to apply, and the development task is deemed more challenging with TDD. Several patterns emerged about how developers approach TDD when developing an ES ( e.g., the participants did not always develop in conformity with TDD). Conclusion: TDD seems to be a promising approach to the development of ESs, even though further research is needed. In this regard, we believe that our results can pave the way for future research with the involvement of software companies and professionals.

Context: A deprecated API ( Application Programming Interface ) is an API that its original developers no longer recommend using. Although deprecated APIs ( i.e., deprecated fields, methods, and classes) are still implemented, they are likely to be removed in future implementations. Consequently, developers are advised against using deprecated APIs in newly written code and are encouraged to update existing code to remove any deprecated API usage. Objective: We aimed to gather preliminary empirical evidence on deprecated API usages in open-source Java applications. Methods: To pursue such a goal, we conducted an exploratory Mining-Software-Repository ( MSR ) study in which we quantitatively analyzed the commit histories of 14 applications whose software projects were top-starred on GitHub. Results: The most important takeaway results of our study can be summarized as follows: (i) deprecated API usages are pretty widespread in the studied software applications; (ii) only in half of these applications, developers remove deprecated API usages as soon as possible; (iii) consuming their own deprecated APIs is a prevalent phenomenon in half of the studied applications; (iv) the introductions and removals of deprecated API usages are mostly due to changes performed by senior contributors; (v) developers mostly introduce and remove deprecated API usages when they are far from publishing a release version; and (vi) the introductions and removals of deprecated API usages are often undocumented in commit messages. Conclusion: The outcomes of our study suggest that developers should better handle deprecated API usages.

In this folklore-confirmation short paper, we present the results of a study on the removal of dead code. We aim to gather evidence on the impact of dead-method removal on the internal structure of source code and the usage of resources such as compilation time and space to store executable code. To that end, we studied 23 open-source Java desktop applications hosted on GitHub. We cleaned up each of these applications from its dead methods to obtain two versions: one with dead methods (i.e., original version) and another one without them (i.e., cleaned version). For each of these applications, we compared its versions (original and cleaned) to determine whether, and to what extent, the removal of dead methods affects the internal structure of source code and the usage of resources. We observed that, after removing dead methods, the internal structure of source code significantly improves, while the time to compile source code significantly diminishes as well as the space to store executable code.

MSR4SBOM (Mining Software Repositories for enhanced Software Bills of Materials) is a project whose main goal is to deliver a framework that analyzes the content of software repositories and SBOMs to provide context-sensitive recommendations. The expected outputs are (i) a set of approaches and tools released as open-source projects, making them exploitable in industrial, academic, and open-source contexts; and (ii) replication packages of our empirical studies and repositories of datasets collected while developing, calibrating, and validating the MSR4SBOM approaches and tools.

In this paper, we present the results of a confirmation study on the impact of dead-method removal on the internal structure of source code, time to compile source code, and space to store compilation results (i.e., executable code). To that end, we cleaned up 23 open-source Java desktop applications hosted on GitHub from their dead methods, obtaining two versions: one with dead methods (i.e., original version) and another one without them (i.e., cleaned version). For each of these applications, we compared its versions (original and cleaned) and found that, after removing dead methods, the internal structure of source code significantly improves, while the time to compile source code significantly diminishes as well as the space to store compilation results. We also performed correlation analyses that allowed us to conclude that the more dead methods are removed, the greater the improvement to the internal structure of source code and the less space to store executable code.

In recent years, a growing interest has been in the adoption of medical web or mobile applications or more in general applications in the digital health (DHEAL) field. These applications are designed for a wide range of users, from novice to expert and also end-users with and without disabilities, without adequately considering their unique software security needs. In this short paper, we present the results of a Rapid Review (RR) to identify existing approaches and methods to assess User Experience (UX), usability, accessibility and/or security in DHEAL applications. This RR has been conducted in the context of a research project (“DHEAL-COM Digital Health Solutions in Community Medicine). Among the others, the objective of DHEAL-COM is to delve into the complex relationship between UX (and its variants, like usability and accessibility) and security, i.e., to understand to what extent the principle of acceptability in security is taken into account when developing DHEAL applications. The outcomes of our RR should provide evidence to the stakeholders involved in the DHEAL-COM project and to researchers and practitioners who work in the DHEAL context. The findings of our RR emerge from 39 papers and can be summarized as follows: (i) there are several methods to assess usability; (ii) the most common methods are focused only on common usability aspects and in a few cases these methods concerns accessibility and credibility of the content; (iii) there are several methods to assess security and most of them are dictated by legislative rules; (iv) although the difficulty in finding a compromise between usability and security is clear in many cases, there are neither solutions nor approaches to deal with both of them.

Test-Driven Development (TDD) is an agile software development approach. It promotes short cycles, composed of three phases each, to incrementally implement software functionality: Red, Green, and Refactor. In the Red Phase, the TDD developer writes a unit test for a small chunk of functionality not yet implemented and watches the test fail. In the Green Phase, the TDD developer writes production code to make the test pass as quickly as possible. Finally, in the refactor phase, the TDD developer “cleans” written code. In this demo paper, we present GAI4-TDD (Generative Artificial Intelligence for Test-Driven Development), a PyCharm plugin to support the Green Phase of TDD. Specifically, this plugin generates production code from the tests the TDD developer had written in the Red Phase so that the generated code makes these tests pass. Previous studies have shown that TDD can be beneficial not only in the “traditional” software development context but also in the Embedded Systems (ESs) development context. We preliminary assessed GAI4-TDD in the latter context through a laboratory empirical study on three ESs. We observed that in the greater part of the cases, GAI4- TDD generates production code that successfully implements the chunk of functionality required. A video showing GAI4- TDD in action is available at: https://youtu.be/30IDb-6NgS4.

Abstract Background.Dead code is a code smell. It can refer to code blocks, fields, methods, etc. that are unused and/or unreachable—e.g., if a method is unused and/or unreachable, it is a dead method. Past research has shown that the presence of dead code in source code harms its comprehensibility and maintainability. Nevertheless, there is still little empirical evidence on the spread of this code smell in the source code of commercial and open-source software applications. Aims.Our goal is to gather, through an exploratory study, empirical evidence on the spread and evolution of dead methods in open-source Java desktop applications. Method.We quantitatively analyzed the commit histories of 23 open-source Java desktop applications, whose software projects were hosted onGitHub. To investigate the spread and evolution of dead methods, we focused on dead methods detected at a commit level. The total number of analyzed commits in our study is 1,587. The perspective of our exploratory study is that of both practitioners and researchers. Results.We can summarize the most important take-away results as follows:(i)dead methods affect open-source Java desktop applications;(ii)dead methods generally survive for a long time before being “buried” or “revived;”(iii)dead methods that are then revived tend to survive less, as compared to dead methods that are then buried;(iv)dead methods are rarely revived; and(v)most dead methods are stillborn, rather than becoming dead later. Given the exploratory nature of our study, we believe that its results will help researchers to conduct more resource- and time-demanding research on dead methods and, in general, on dead code. Conclusions.We can conclude that developers should carefully handle dead code (and thus dead methods) since it is harmful, widespread, rarely revived, and survives for a long time in software applications.

Background: Dead code is a code smell. It can refer to code blocks, variables, parameters, fields, methods, classes, etc. that are unused and/or unreachable. Aim: Results from past empirical studies indicate that dead code is widespread in both desktop and web-based software applications. Also, researchers have shown that both comprehensibility and maintainability of source code are negatively affected when dead code is present. Nevertheless, we still know little about maintenance operations involving dead code. Method: We conducted an exploratory empirical study on 13 open-source Java desktop applications, whose software projects were hosted on GitHub, to provide preliminary evidence on whether, and to what extent, developers modify dead code—more specifically, dead methods—when they deal with the maintenance of open-source Java desktop applications. Results: The most important results of our study can be summarized as follows: (i) developers modify dead methods; (ii) dead methods are modified to a different extent as compared to alive methods; (iii) developers spend time modifying dead methods that are removed in subsequent commits; and (iv) developers modify dead methods that are later revived to a different extent as compared to dead methods that are later removed. Conclusions: One of the conclusions of our study is: developers should remove dead methods, whose presence and purpose are not properly documented, to avoid unnecessary modifications to dead methods during the maintenance of software applications.

Background. Dead code is a code smell. It can refer to code blocks, fields, methods, etc. that are unused and/or unreachable. Empirical evidence shows that dead code harms source code comprehensibility and maintainability in software applications. Researchers have gathered little empirical evidence on the spread of dead code in software applications. Moreover, we know little about the role of this code smell during software evolution.