Fuzzing has become a popular technique for automatically detecting vulnerabilities and bugs by generating unexpected inputs. In recent years, the fuzzing process has been integrated into continuous integration workflows (i.e., continuous fuzzing), enabling short and frequent testing cycles. Despite its widespread adoption, prior research has not examined whether the effectiveness of continuous fuzzing varies across programming languages.

Software vulnerabilities are constantly being reported and exploited in software products, causing significant impacts on society. In recent years, the main approach to vulnerability detection, fuzzing, has been integrated into the continuous integration process to run in short and frequent cycles. This continuous fuzzing allows for fast identification and remediation of vulnerabilities during the development process. Despite adoption by thousands of projects, however, it is unclear how continuous fuzzing contributes to vulnerability detection.This study aims to elucidate the role of continuous fuzzing in vulnerability detection. Specifically, we investigate the coverage and the total number of fuzzing sessions when fuzzing bugs are discovered. We collect issue reports, coverage reports, and fuzzing logs from OSS-Fuzz, an online service provided by Google that performs fuzzing during continuous integration. Through an empirical study of a total of approximately 1.12 million fuzzing sessions from 878 projects participating in OSS-Fuzz, we reveal that (i) a substantial number of fuzzing bugs exist prior to the integration of continuous fuzzing, leading to a high detection rate in the early stages; (ii) code coverage continues to increase as continuous fuzzing progresses; (iii) changes in coverage contribute to the detection of fuzzing bugs; and (iv) developer-provided seed corpus exhibit long-term effectiveness. This study provides empirical insights into how continuous fuzzing contributes to fuzzing bug detection, offering practical implications for future strategies and tool development in continuous fuzzing.

Refactoring is a widely applied practice for improving the internal structure of source code without altering its external behavior. Researchers have proposed approaches to detect refactoring operations and investigated their impact on the code quality. However, these studies often focus on production code, paying little attention to test code. It is still unclear whether developers perform refactoring on test code in the same way or for the same purpose. To fill this gap, we first investigate the types and prevalence of refactoring applied in production and test code, and then examine whether these refactorings impact the code quality in a different way. Our results show that certain refactorings are less common in the test code. Besides, while refactoring-related changes in production and/or test code improved readability, they had limited impact on most design smells. We also find that some specific refactoring types do impact certain design smells. These findings indicate the special attention needed for test code when analyzing refactorings.

Self-Admitted Technical Debt (SATD) refers to nonoptimal software design or implementation that is acknowledged and explicitly documented in the code by developers. Detecting SATD and understanding its evolution can help developers better manage their development activities and monitor the software quality. In recent years, numerous approaches have been proposed to automatically identify SATD. However, these approaches still suffer from a high number of false positives (i.e., non-SATD comments being detected as SATD). To further advance this field, in this paper, we conduct an empirical study to evaluate the performance of the state-of-theart SATD detection tools and investigate the causes behind the false positives. By manually analyzing 135 false positive cases, we identify the main types of comments that are easily misclassified. To address this issue, we propose a new approach, CASTI, which integrates context information into CodeBERT, a pre-trained model for programming languages. Our evaluation demonstrates that CASTI can significantly reduce the false positives and that the context information does help improve the performance.

Code review plays an important role in quality assurance, which improves readability, maintainability, etc. On the other hand, code review is notorious for being very time-consuming work because reviewers need to carefully inspect numerous lines for each change. To alleviate the efforts, many studies have proposed approaches to highlighting the code that reviewers need to review. However, even using the finest-grained approaches (i.e., line-level), the granularity of the recommendations is coarse-grained so it is difficult for developers to figure out what needs to be reviewed. For example, lines in the QtBase projects have a median of 7 tokens and sometimes have more than 12 tokens (10% of the lines). This study proposes a token level approach to recommend where developers review, which is finer-grained than the previous studies. Specifically, we fine-tune CodeBERT so that it can return the tokens that are most likely to be commented on and revised. Our empirical evaluation using the OpenStack and QtBase datasets demonstrated that the proposed approach outperforms the state-of-the-art model to predict lines to be revised. Also, we find that 86% of the predicted tokens are accurately distinguished as either needing modification or not when the lines to be revised are correctly identified.

Docker plays a crucial role in providing uniform software development. Many Docker development projects deliver multiple images in order to support various users who need different base images, versions, and architectures. To do so, the projects need to develop different contents of Dockerfiles for each support. For example, if developers provide their product on different Linux OSs, Dockerfiles need to contain package installing commands with an appropriate package manager for each Linux OS. To reduce the development tasks, many projects often develop their own tool to generate multiple Docker images automatically (hereafter, Dockerfile Preprocessors). However, it is still not clear how the projects adopt Dockerfile Preprocessors and what the benefits are. This study explores the characteristics of projects using Dockerfile Preprocessors, the timing, impact, and purpose, and the maintenance effort of using Dockerfile Preprocessors. Our empirical results show that (i) there is “Container build” pattern that does not generate multiple Dockerfiles; (ii) Projects using DPPs have more tags, supported Docker images, and architecture supports than projects without DPPs; (iii) 66% of projects develop DPPs in the middle of development; (iv) the common reasons for adopting DPP is to reduce the effort of creating Dock-erfiles, and to ease updating versions/variations/architectures; (v) the adoption of DPPs does not increase releasing activities.

Code completion has the benefit of improving coding speed and reducing the chance of inducing bugs. In recent years, DL-based code completion techniques have been proposed. In particular, pre-trained models have shown outstanding performance because they can complete code by considering the context before and after it is completed. While the model can generate the set of candidate codes, some of those might need to be modified by developers because projects can have different coding rules.In this study, to complete code that fits a specific project appropriately, we train the CodeT5 model with additional data from the target project. This fine-tuning approach is called do-main adaptation, and is often used in neural machine translation. Our preliminary experiment observes that our domain-adapted model improves 5.3% of the perfect prediction rate and, 3.4% of the edit distance rate, compared to the fine-tuned model with the out-of-domain dataset. Furthermore, we discover that the improvement is greater with a larger repository size. The model that is trained with a small dataset, however, hardly improves or performs worse.

Recently, various institutions have been conducting advanced programming education aimed at experiencing agile software development in the form of project-based learning (PBL). In the agile software development model, an essential part is the build process. In this study, we investigated students' build behaviors in agile software development PBL (SDPBL) by monitoring and collecting logs of the build process from 2013 to 2016. In our investigation, we collected two types of logs, the local build logs collected by each student's build in their own local programming environment, and remote build logs collected by any team member's commit in team repository. Based on our analysis of the build logs from 2013 to 2015, we found that the causes of remote build errors are related to both technical factors and communications among students in a team. In 2016, the instructors tried to educate to students the reason why the remote build error occur and how it can be resolved. As a result, in 2016, the number of remote build errors and the time required to solve the build errors decreased compared to previous years. It indicates a possibility that the student's comprehension of build error is effective on improving quality of software product and team development.

Extract Method is one of the most widely used refactoring patterns. So far, low quality of source code has been regarded as an indicator for Extract Method opportunities. However, recent studies showed that there is no clear relationship between source code quality and Extract Method. Change metrics can be indicators for Extract Method because the characteristics of software evolution strongly affect software quality. However, there has been no study that investigated the relationship between change metrics and Extract Method. In this study, we conducted two studies investigating the relationship between Extract Method and change metrics. As a result, we found that (1) change metrics have a clear relationship with Extract Method and (2) both product and change metrics are necessary to recommend candidates for Extract Method with high accuracy.

In the research of Mining Software Repositories, source code repositories are one of the core sources since it contains the product and the process of software development. A source code repository stores the versions of files and makes it possible to browse the histories of files, such as modification dates, authors, messages, so on. Although such rich information of file histories is easily available, extracting the histories of methods/functions, which are elements of source code files, is not easy from general code repositories. To tackle this difficulty, we have developed Historage, a fine-grained version control system. Historage repository is a Git repository, which is built upon an original Git repository. Therefore, similar mining techniques for general Git repositories are applicable to Historage repositories. We also have developed Kataribe, a hosting service of Historage repositories, which contains hundreds of Historage repositories constructed from repositories in GitHub, which are written in C#, Java, Python and Ruby. The list of all Historage and original repositories are available at http://kataribe.naist.jp/public. With this dataset, we will promote in-depth and fine-grained software evolution research with diversity of programming languages.

Developers often perform the repeating cycle of implementation and evaluation when they need to deal with the unfamiliar portion of the source code. This cycle is named as exploratory programming. We regard exploratory programming as an effective way not only to improve novice's programming skill but also to support educators in programming exercise in University. Because when novices often use the exploratory programming, it means novices struggle to solve their assignments. Therefore, educators should grasp which elements, APIs or blocks novices often used exploratory programming for. In this paper, firstly we propose the definition of novice's exploratory programming to collect logs of exploratory based on various granularity by novices. Secondly, we propose an algorithm based on our proposed definition to automatically detect exploratory programming behaviors. We also conducted a small case study. As a result of automatic detection, our proposed algorithm allows us to know what elements of program novices often feel difficult and struggle for.

ReDA (http://reda.naist.jp/) is a web-based visualization tool for analyzing Modern Code Review (MCR) datasets for large Open Source Software (OSS) projects. MCR is a commonly practiced and lightweight inspection of source code using a support tool such as Gerrit system. Recently, mining code review history of such systems has received attention as a potentially effective method of ensuring software quality. However, due to increasing size and complexity of softwares being developed, these datasets are becoming unmanageable. ReDA aims to assist researchers of mining code review data by enabling better understand of dataset context and identifying abnormalities. Through real-time data interaction, users can quickly gain insight into the data and hone in on interesting areas to investigate. A video highlighting the main features can be found at: http://youtu.be/ fEoTRRas0U.

In the research of Mining Software Repositories, code repository is one of the core source since it contains the product of software development. Code repository stores the versions of files, and makes it possible to browse the histories of files, such as modification dates, authors, messages, etc. Although such rich information of file histories is easily available, extracting the histories of methods, which are elements of source code files, is not easy from general code repositories. To tackle this difficulty, we have developed Historage, a fine-grained version control system. Historage repository is a Git repository which is built upon original Git repository. Therefore, similar mining techniques for general Git repositories are applicable to Historage repositories. Kataribe is a hosting service of Historage repositories, which enables researchers and developers to browse method histories on the web and clone Historage repositories to local. The Kataribe project aims to maintain and expand the datasets and features.

We present four datasets that are focused on the general roles of OSS peer review members. With data mined from both an integrated peer review system and code source repositories, our rich datasets comprise of peer review data that was automatically recorded. Using the Android project as a case study, we describe our extraction methodology, the datasets and their application used for three separate studies. Our datasets are available online at http://sdlab.naist.jp/reviewmining/.

Due to the distributed collaborations and the volunteering nature of Open Source Software (OSS), OSS peer review processes differs from traditional approaches. Despite the latest research efforts to understand OSS peer review processes, very little is known. Unlike related work, this study investigates OSS peer review processes from a different perspective. We investigate the importance of OSS peer review contributor roles and their review activities by using social network analysis (SNA), proposed as PeRSoN (Peer Review Social Network). As a case study, we extracted and analyzed the review process of Android Open Source Project (AOSP). To the best of our knowledge, this is the first research constructing social networks from mining a peer review repository. Our preliminary results provided hints on relationships among the OSS peer review contributor roles, their activities, and the network structure. The results raised issues that will be used to refine our approach in the future.