SearcharxivSearch

arXiv subjects

Lawrence Arkoh

Publications and source records attributed to Lawrence Arkoh.

4 recordsLinked to original sources

Where are the Hidden Gems? Applying Transformer Models for Design Discussion Detection

Design decisions are at the core of software engineering and appear in Q\&A forums, mailing lists, pull requests, issue trackers, and commit messages. Design discussions spanning a project's history provide valuable information for informed decision-making, such as refactoring and software modernization. Machine learning techniques have been used to detect design decisions in natural language discussions; however, their effectiveness is limited by the scarcity of labeled data and the high cost of annotation. Prior work adopted cross-domain strategies with traditional classifiers, training on one domain and testing on another. Despite their success, transformer-based models, which often outperform traditional methods, remain largely unexplored in this setting. The goal of this work is to investigate the performance of transformer-based models (i.e., BERT, RoBERTa, XLNet, LaMini-Flan-T5-77M, and ChatGPT-4o-mini) for detecting design-related discussions. To this end, we conduct a conceptual replication of prior cross-domain studies while extending them with modern transformer architectures and addressing methodological issues in earlier work. The models were fine-tuned on Stack Overflow and evaluated on GitHub artifacts (i.e., pull requests, issues, and commits). BERT and RoBERTa show strong recall across domains, while XLNet achieves higher precision but lower recall. ChatGPT-4o-mini yields the highest recall and competitive overall performance, whereas LaMini-Flan-T5-77M provides a lightweight alternative with stronger precision but less balanced performance. We also evaluated similar-word injection for data augmentation, but unlike prior findings, it did not yield meaningful improvements. Overall, these results highlight both the opportunities and trade-offs of using modern language models for detecting design discussion.

cs.SE

Secure or Suspect? Investigating Package Hallucinations of Shell Command in Original and Quantized LLMs

Large Language Models for code (LLMs4Code) are increasingly used to generate software artifacts, including library and package recommendations in languages such as Go. However, recent evidence shows that LLMs frequently hallucinate package names or generate dependencies containing known security vulnerabilities, posing significant risks to developers and downstream software supply chains. At the same time, quantization has become a widely adopted technique to reduce inference cost and enable deployment of LLMs on resource-constrained environments. Despite its popularity, little is known about how quantization affects the correctness and security of LLM-generated software dependencies while generating shell commands for package installation. In this work, we conduct the first systematic empirical study of the impact of quantization on package hallucination and vulnerability risks in LLM-generated Go packages. We evaluate five Qwen model sizes under full-precision, 8-bit, and 4-bit quantization across three datasets (SO, MBPP, and paraphrase). Our results show that quantization substantially increases the package hallucination rate (PHR), with 4-bit models exhibiting the most severe degradation. We further find that even among the correctly generated packages, the vulnerability presence rate (VPR) rises as precision decreases, indicating elevated security risk in lower-precision models. Finally, our analysis of hallucinated outputs reveals that most fabricated packages resemble realistic URL-based Go module paths, such as most commonly malformed or non-existent GitHub and golang.org repositories, highlighting a systematic pattern in how LLMs hallucinate dependencies. Overall, our findings provide actionable insights into the reliability and security implications of deploying quantized LLMs for code generation and dependency recommendation.

cs.SE

Assessing the Bug-Proneness of Refactored Code: A Longitudinal Multi-Project Study

Refactoring is a common practice in software development, aimed at improving the internal code structure in order to make it easier to understand and modify. Consequently, it is often assumed that refactoring makes the code less prone to bugs. However, in practice, refactoring is a complex task and applied in different ways (e.g., various refactoring types, single vs. composite refactorings) and with a variety of purposes (e.g., root-canal vs. floss refactoring). Therefore, certain refactorings can inadvertently make the code more prone to bugs. Unfortunately, there is limited research in the literature on the long-term relationship between the different characteristics of refactorings and bugs. This paper presents a longitudinal study of 12 open source software projects, where 27,450 refactorings, 6,051 reported bugs, and 49,250 bugs detected with static analysis tools were analyzed. While our study confirms the common intuition that refactored code is less bug-prone than non-refactored code, we also extend or contradict existing body of knowledge in other ways. First, a code element that undergoes multiple refactorings is not less bug-prone than an element that undergoes a single refactoring. A single refactoring is the one not performed in conjunction with other refactorings in the same commit. Second, single refactorings often induce the occurrence of bugs across all analyzed projects. Third, code elements affected by refactorings made in conjunction with other non-refactoring changes in the same commit (i.e., floss refactorings) are often bug-prone. Finally, many of such bugs induced by refactoring cannot be revealed with state-of-the-art techniques for detecting behavior-preserving refactorings.

cs.SE

Relating Complexity, Explicitness, Effectiveness of Refactorings and Non-Functional Requirements: A Replication Study

Refactoring is a practice widely adopted during software maintenance and evolution. Due to its importance, there is extensive work on the effectiveness of refactoring in achieving code quality. However, developer's intentions are usually overlooked. A more recent area of study involves the concept of self-affirmed refactoring (SAR), where developers explicitly state their intent to refactor. While studies on SAR have made valuable contributions, they provide little insights into refactoring complexity and effectiveness, as well as the refactorings' relations to specific non-functional requirements. A study by Soares et al. addressed such aspects, but it relied on a quite small sample of studied subject systems and refactoring instances. Following the empirical method of replication, we expanded the scope of Soares et al.'s study by doubling the number of projects analyzed and a significantly larger set of validated refactorings (8,408). Our findings only partially align with the original study. We observed that when developers explicitly state their refactoring intent, the resulting changes typically involve a combination of different refactoring types, making them more complex. Additionally, we confirmed that such complex refactorings positively impact code's internal quality attributes. While refactorings aimed at non-functional requirements tend to improve code quality, our findings only partially align with the original study and contradict it in several ways. Notably, SARs often result in fewer negative impacts on internal quality attributes despite their frequent complexity. These insights suggest the importance of simplifying refactorings where possible and explicitly stating their goals, as clear intent helps shape more effective and targeted refactoring strategies.

cs.SE