Part-of-Speech (POS) tags are natural attributes of words in natural languages, and they are fundamental for natural language analysis. Many automated approaches have been proposed to tag natural language texts. Identifiers in source code have POS tags as well, which are useful for various source code analysis tasks, like code search, code comment generation, and code completion. Currently, state-of-the-art POS taggers originally designed for natural languages are often employed to tag source code identifiers. However, identifiers in source code are significantly different from natural languages. Consequently, POS taggers designed for natural languages could be less accurate in source code identifiers. Recently, several identifier-specific taggers have been proposed within the field of software engineering, but their adoption in practical software engineering tasks remains limited. This raises the question of why these taggers have not been more widely utilized in such tasks. In this article, we investigate the performance of natural language POS taggers on source code identifiers, specifically method names, parameter names, and class names. To do so, we manually annotated identifiers from open source projects in Java, C, and Python, creating a large dataset IDData for evaluation. We then evaluated six widely used natural language POS taggers: NLTK, CoreNLP, OpenNLP, spaCy, Flair, and Stanza, alongside three identifier-specific taggers: SWUM, POSSE, and Ensemble Tagger. Our evaluation reveals that while natural language-oriented POS taggers outperform identifier-specific taggers, their performance on identifiers is still significantly lower compared to their performance on natural language sentences. To understand the underlying reasons for this, we conducted an in-depth analysis, examining factors such as identifier length, POS distribution, syntactic structures, and special tags, which differentiate identifiers from natural language sentences. To further improve POS tagging performance on identifiers, we created a large-scale method name dataset MNTrain with manually labeled tags and retrained the natural language taggers on this new dataset. The results show substantial improvements in method name POS tagging performance, with taggers achieving performance comparable to their results on natural language sentences. Finally, we discuss the significance and practical implications of our findings, offering insights for future research.

In software development, many documents (e.g., tutorials for tools and mobile application websites) contain screenshots of GUIs to illustrate functionalities. Although screenshots are critical in such documents, screenshots can become outdated, especially if document developers forget to update them. Outdated screenshots can mislead users and diminish the credibility of documentation. Identifying screenshots manually is tedious and error-prone, especially when documents are numerous. However, no existing tools are proposed to detect outdated screenshots in GUI documents. To mitigate manual efforts, we propose DOSUD , a novel approach for detecting outdated screenshots. It is challenging to identify outdated screenshots since the differences are subtle and only specific areas are useful to identify such screenshots. To address the challenges, DOSUD automatically extracts and labels screenshots and trains a classification model to identify outdated screenshots. As the first exploration, we focus on Android applications and the most popular IDE, VS Code. We evaluated DOSUD on a benchmark comprising 10 popular applications, achieving high F1-scores. When applied in the wild, DOSUD identified 20 outdated screenshots across 50 Android application websites and 17 outdated screenshots in VS Code documentation. VS Code developers have confirmed and fixed all our bug reports.

Manually creating concise and meaningful method names is often challenging and time-consuming for software engineers, especially for less experienced and non-native English speakers. They may find it easier to provide functional descriptions in their native languages; however, this practice results in inherent ambiguities (e.g., natural language, semantic gaps, cultural misinterpretations) and limited lexical overlap with English names. To address these challenges, this paper presentsLangInsightCraft, a novel context-rich prompt generation algorithm to guide LLMs in suggesting method names from cross-language functional descriptions. From the input description, it retrieves similar high-quality native examples and extracts key contextual elements (e.g., entities, actions, functionality scope) from descriptions of these examples, to overcome inherent ambiguities. It also generates a set of candidate method names for each example’s description, evaluates them against the example’s method name using edit-distance and a semantic similarity index, and ranks them by alignment score. Using these ranked names,LangInsightCraftgenerates an English textual explanation for each candidate name, which helps LLM handle the challenge of limited lexical overlap between English method names and non-English descriptions. Finally, it embeds these outputs, input and examples into a predefined prompt template to generate a context-rich prompt for LLM to generate the expected method name. Evaluated on 64,815 Java methods with English/Chinese descriptions,LangInsightCraftsubstantially outperformsRNN-att-Copy, improving exact-match by 54% and 122%, and decreasing edit-distance by 33% and 54%, on English and Chinese datasets respectively, while generalizing well across different LLMs.

Open source software (OSS) development widely adopts modern code review to identify issues and guarantee code quality. As reported repeatedly, maintainers are under heavy workloads when reviewing code changes. Meanwhile, we notice that some code reviews were overlooked by the authors of the code changes, i.e., neither causing code modification nor being replied to. These code reviews, if requiring responses but not receiving any, might represent a significant inefficiency, risk of overlooking critical issues, and problematic social exchange. Moreover, leaving code reviews publicly unanswered may cause a negative impression on both the corresponding OSS contributors and the OSS projects. Existing literature on code review mainly focuses on the usefulness of code reviews, reviewer recommendations, factors affecting PR acceptance, and review comment generation; the nature of overlooked reviews has not been explored. To this end, we focus on a widely-used modern code review mechanism, i.e., reviewing Pull Request (PR) code before merge, and conduct the first empirical study on 80 Java OSS projects to explore the prevalence, characteristics, rationales, and possible impact of the overlooked code reviews. We find that approximately 7.5% of PRs have at least one review comment being ignored. We further show that pull requests containing no-response comments are significantly associated with longer review lifecycles and lower acceptance rates, indicating measurable negative outcomes beyond their modest prevalence. Then, we categorize these no-response comments through thematic analysis and find two main categories with seven subcategories: Review inquiry and PR management. We also extract four subcategories in Review inquiry, e.g., Give suggestions about code implementation, Point out implementation issues, and Additional task requests. PR management consists of three subcategories, i.e., PR status checks, PR merge conflict notifications, and Reject PR with uncertain reasons. To better understand the existence of no-response comments, we surveyed developers and received 45 responses. We found that the reasons for the existence of no-response comments are diverse, such as prolonged review times and a lack of consensus on opinions. Developers also hold the consensus that ignored reviews will have negative effects on software projects. These findings emphasize the need for attention from both academia and industry to the responses to review comments and optimization of the reminder mechanism.

Utilizing third-party open source libraries is fundamental to modern software development because it can enhance productivity and software quality. However, libraries may cease maintenance and become deprecated, negatively impacting the projects that rely on them. Promptly identifying and addressing deprecated libraries can help developers mitigate potential risks within their projects. As a programming language known for its emphasis on safety, Rust’s package manager currently does not provide a direct mechanism for deprecation. Nevertheless, Rust developers can still declare deprecation using certain methods offered by GitHub and the official Rust package registry, crates.io. However, the current usage of these deprecation mechanisms in the Rust ecosystem, as well as their effectiveness, remains underexplored. This paper addresses this gap by empirically studying the prevalence of deprecation declarations in Rust libraries, the effectiveness of different ways of declarations, and the reasons for using deprecated libraries to understand how deprecation information is disseminated and perceived in the current Rust ecosystem. We found that: 1) Among the 13,289 inactive libraries in the Rust ecosystem, only 11% of them indicate their deprecated status; 2) Among the packages that released a new version after their dependent library declared deprecation, 38.9% still chose to use the deprecated library in their new releases; 3) Despite developers being able to actively or passively discover deprecated libraries within their projects through various means, unawareness of library deprecation is a significant reason for developers using deprecated libraries. Based on these findings, we discuss practice insights to help improve the deprecation mechanism and mitigate software dependency risks.

Text-to-image (T2I) diffusion models have shown exceptional capabilities in generating images that closely correspond to textual prompts. However, the advancement of T2I diffusion models presents significant risks, as the models could be exploited for malicious purposes, such as generating images with violence or nudity, or creating unauthorized portraits of public figures in inappropriate contexts. To mitigate these risks, concept removal methods have been proposed. These methods aim to modify diffusion models to prevent the generation of malicious and unwanted concepts. Despite these efforts, existing research faces several challenges: (1) a lack of consistent comparisons on a comprehensive dataset, (2) ineffective prompts in harmful and nudity concepts, (3) overlooked evaluation of the ability to generate the benign part within prompts containing malicious concepts. To address these gaps, we propose to benchmark the concept removal methods by introducing a new dataset, Six-CD, along with a novel evaluation metric. In this benchmark, we conduct a thorough evaluation of concept removals, with the experimental observations and discussions offering valuable insights in the field.

Shenglai Zeng, Jiankun Zhang, Pengfei He, Jie Ren, Tianqi Zheng, Hanqing Lu, Han Xu, Hui Liu, Yue Xing, Jiliang Tang. Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing. 2025.

Software refactoring is widely employed to improve software quality. However, conducting refactorings manually is tedious, time-consuming, and error-prone. Consequently, automated and semi-automated tool support is highly desirable for software refactoring in the industry, and most of the main-stream IDEs provide powerful tool support for refactoring. However, complex refactoring engines are prone to errors, which in turn may result in imperfect and incorrect refactorings. To this end, in this paper, we propose a ChatGPT-based approach to testing refactoring engines. We first manually analyze bug reports and test cases associated with refactoring engines, and construct a feature library containing fine-grained features that may trigger defects in refactoring engines. The approach automatically generates prompts according to both predefined prompt templates and features randomly selected from the feature library, requesting ChatGPT to generate test programs with the requested features. Test programs generated by ChatGPT are then forwarded to multiple refactoring engines for differential testing. To the best of our knowledge, it is the first approach in testing refactoring engines that guides test program generation with features derived from existing bugs. It is also the first approach in this line that exploits LLMs in the generation of test programs. Our initial evaluation of four main-stream refactoring engines suggests that the proposed approach is effective. It identified a total of 115 previously unknown bugs besides 28 inconsistent refactoring behaviors among different engines. Among the 115 bugs, 78 have been manually confirmed by the original developers of the tested engines, i.e., IntelliJ IDEA, Eclipse, VScode-Java, and NetBeans.

Microservice is a popular architecture to construct applications from a set of small independent services in cloud environment, leading to high cohesion, high availability, low coupling, and decent scalability. Due to large number of independent services in a microservice system, system faults generated from a single service would propagate to multiple services, eventually degraded the overall system performance and Quality of Service (QoS). Thus, it is crucial to efficiently and autonomously diagnose the runtime system fault. However, the complexity and dynamism of microservice systems and cloud environment pose unique challenges to precisely and robustly identify the faults and localize the root causes. In this paper, we propose an Autonomous Model Selection-Ensemble-Stacking (AMSES) framework for microservice system fault identification. The proposed framework can automatically select, ensemble, and stack optimal models from candidate unsupervised detection models for identifying different fault types robustly. In addition, AMSES can adaptively localize the fault services using autoselected root cause localization model. Moreover, by exploiting the fault degree and causal inferring score, we can diagnose the detected system fault precisely and interpretably. To evaluate the effectiveness, we empirically compare AMSES with state-of-the-art models on three kinds of faults on two microservice benchmarks: Sock-Shop and Train-Ticket. The experimental results show that AMSES can achieve$\mathbf{8 7. 1 \%}$and$\mathbf{9 1. 4 \%}$macroF1 average for fault type identification on Sock-Shop and TrainTicket, respectively. Meanwhile, AMSES could outperform its competitors for root cause localization with an average Avg@5 of 0.856 on Sock-Shop and 0.633 on Train-Ticket.

Copy-paste-modify is a widespread and pragmatic practice in software development, where developers adapt reused code snippets, sourced from platforms such as Stack Overflow, GitHub, or LLM outputs, into their local codebase. A critical yet underexplored aspect of this adaptation is code wiring: the context-aware process of substituting unresolved variables in pasted code with suitable variables or expressions from the surrounding context. Existing solutions either rely on heuristic rules or historical templates, often failing to effectively utilize contextual information, despite studies showing that over half of adaptation cases are context-dependent. In this paper, we introduce WIRL, an LLM-based agent for code wiring framed as a Retrieval-Augmented Generation (RAG) infilling task. WIRL combines an LLM, a customized toolkit, and an orchestration module to identify unresolved variables, retrieve context, and perform context-aware substitutions. To balance efficiency and autonomy, the agent adopts a mixed strategy: deterministic rule-based steps for common patterns, and a state-machine-guided decision process for intelligent exploration. We evaluate WIRL on a carefully curated, high-quality dataset consisting of real-world code adaptation scenarios. Our approach achieves an exact match precision of 91.7% and a recall of 90.0%, outperforming advanced LLMs by 22.6 and 13.7 percentage points in precision and recall, respectively, and surpassing IntelliJ IDEA by 54.3 and 49.9 percentage points. These results underscore its practical utility, particularly in contexts with complex variable dependencies or multiple unresolved variables. We believe WIRL paves the way for more intelligent and context-aware developer assistance in modern IDEs.

Code review is critical for ensuring software quality and maintainability. With the rapid growth in software scale and complexity, code review has become a bottleneck in the development process because of its time-consuming and knowledge-intensive nature and the shortage of experienced developers willing to review code. Several approaches have been proposed for automatically generating code reviews based on retrieval, neural machine translation, pre-trained models, or large language models (LLMs). These approaches mainly leverage historical code changes and review comments. However, a large amount of crucial information for code review, such as the context of code changes and prior review knowledge, has been overlooked. This paper proposes an LLM-based review knowledge-augmented, context-aware framework for code review generation, named LAURA. The framework integrates review exemplar retrieval, context augmentation, and systematic guidance to enhance the performance of ChatGPT-4o and DeepSeek v3 in generating code review comments. Besides, given the extensive low-quality reviews in existing datasets, we also constructed a high-quality dataset. Experimental results show that for both models, LAURA generates review comments that are either completely correct or at least helpful to developers in 42.2% and 40.4% of cases, respectively, significantly outperforming SOTA baselines. Furthermore, our ablation studies demonstrate that all components of LAURA contribute positively to improving comment quality.

Although Large Language Models (LLMs) have demonstrated impressive capabilities across a wide range of tasks, growing concerns have emerged over the misuse of sensitive, copyrighted, or harmful data during training. To address these concerns, unlearning techniques have been developed to remove the influence of specific data without retraining from scratch. However, this paper reveals a critical vulnerability in fine-tuning-based unlearning: a malicious user can craft a manipulated forgetting request that stealthily degrades the model’s utility for benign users. We demonstrate this risk through a red-teaming Stealthy Attack (SA), which is inspired by two key limitations of existing unlearning—the inability to constrain the scope of unlearning effect and the failure to distinguish benign tokens from unlearning signals. Prior work has shown that unlearned models tend to memorize forgetting data as unlearning signals, and respond with hallucinations or feigned ignorance when unlearning signals appear in the input. By subtly increasing the presence of common benign tokens in the forgetting data, SA enhances the connection between benign tokens and unlearning signals. As a result, when normal users include such tokens in their prompts, the model exhibits unlearning behaviors, leading to unintended utility degradation. To address this vulnerability, we propose Scope-aware Unlearning (SU), a lightweight enhancement that introduces a scope term into the unlearning objective, encouraging the model to localize the forgetting effect. Our method requires no additional data processing, integrates seamlessly with existing fine-tuning frameworks, and significantly improves robustness against SA. Extensive experiments validate the effectiveness of both SA and SU.

Abstract Researchers have recently achieved significant advances in deep learning techniques, which in turn has substantially advanced other research disciplines, such as natural language processing, image processing, speech recognition, and software engineering. Various deep learning techniques have been successfully employed to facilitate software engineering tasks, including code generation, software refactoring, and fault localization. Many studies have also been presented in top conferences and journals, demonstrating the applications of deep learning techniques in resolving various software engineering tasks. However, although several surveys have provided overall pictures of the application of deep learning techniques in software engineering, they focus more on learning techniques, that is, what kind of deep learning techniques are employed and how deep models are trained or fine-tuned for software engineering tasks. We still lack surveys explaining the advances of subareas in software engineering driven by deep learning techniques, as well as challenges and opportunities in each subarea. To this end, in this study, we present the first task-oriented survey on deep learning-based software engineering. It covers twelve major software engineering subareas significantly impacted by deep learning techniques. Such subareas spread out through the whole lifecycle of software development and maintenance, including requirements engineering, software development, testing, maintenance, and developer collaboration. As we believe that deep learning may provide an opportunity to revolutionize the whole discipline of software engineering, providing one survey covering as many subareas as possible in software engineering can help future research push forward the frontier of deep learning-based software engineering more systematically. For each of the selected subareas, we highlight the major advances achieved by applying deep learning techniques with pointers to the available datasets in such a subarea. We also discuss the challenges and opportunities concerning each of the surveyed software engineering subareas.

As massive data is generated by Internet of Things (IoT) devices, user-end devices are required to implement computation-intensive functionalities, including multi-sensory data processing and analysis, sophisticated system control schemes, and artificial intelligence. Mobile Edge Computing (MEC) is a significant technology that has the potential to extend the computation and storage capacities of user-end devices by the decentralization of required resources and contents near users and at the edge. A crucial challenge in this direction is the development of a smart mechanism to effectively cache contents upon Edge Servers (ESs) near users for high effectiveness and low latency of content delivery with the constraints on computational and storage capacities of ESs. This study employs a queuing model for analyzing total request delay and interprets the content caching problem as an adversarial semi-bandits problem. We propose an Online Self-feedback Adversarial Semi-bandits Learning (OSAL) algorithm that incorporates a dual-layer learning architecture for dynamically generating caching strategies and maximizes the long-term reward. Experimental results demonstrate that the proposed method significantly outperforms the state-of-the-art methods across various performance metrics in a real-world multi mobile-user content caching case.

Mobile applications are widely used by billions of users in their daily work and life. Such GUI software is prone to bugs, potentially degrading user experience. Notably, many bugs in mobile apps are reported by end-users who cannot access the requirements of the app or test cases accompanied by explicitly specified test oracles. It may suggest that such bugs are not identified in the traditional way, i.e., by comparing the actual behaviors of the apps against their expected behaviors explicitly specified in the requirements or test cases. Instead, such bugs are often identified by comparing the actual behaviors against users’ common knowledge of apps, noted as common sense. We refer to such bugs as common sense-violating bugs. Although it is well-known that common sense-violating bugs are common in mobile apps, it remains unclear how popular they are and what kind of common sense principles are violated by them, let alone the relationship among the violated common sense principles. To this end, in this paper, we conduct the first large-scale empirical study on common sense-violating bugs in open-source mobile apps. We manually analyzed 2,808 real-world bug reports across 948 open-sourced mobile apps on GitHub. Our analysis results suggest that 1,006 (35.8%) out of the 2,808 bugs pertain to common sense-violating bugs. From those common sense-violating bugs, we identified a set of common sense principles violated by the buggy behaviors, and built a taxonomy for the common sense principles. Such principles fall into three categories: UI content-related common sense principles, UI layout-related common sense principles, and interaction-related common sense principles. By analyzing the frequency of the common sense principles being violated, we observed that a small set of common sense principles were frequently violated by the majority of common sense-violating bugs: 18 common sense principles, accounting for only 5% of the violated common sense principles, were violated by more than half of the common sense-violating bugs. These findings suggest that identifying the most frequent common sense-violating bugs could be achieved by using a small set of critical common sense principles, which may significantly reduce the cost of common sense-based bug detection. Finally, to demonstrate the feasibility of automated bug detection with common sense-based test oracles, we propose an automated approach to validating whether a given test run violates the most frequently violated common sense principle: No raw error message. Our evaluation results suggest that the automated approach is accurate, whose precision and recall are 91.3% and 91.6%, respectively.

Extracting local variable refactoring is frequently employed to replace one or more occurrences of a complex expression with simple accesses to a newly introduced variable. To facilitate refactoring, most IDEs can automate the extract local variable refactorings when the to-be-extracted expressions are selected by developers. However, refactoring tools usually replace all expressions that are lexically identical to the selected one without a comprehensive analysis of the safety of the refactoring. The automatically conducted refactorings may lead to serious software defects. Besides that, existing refactoring tools rely heavily on software developers to spot to-be-extracted expressions although it is often challenging for inexperienced developers and maintainers to make the selection. To this end, in this article, we propose an automated approach, called ValExtractor+ , to recommending extract local variable refactoring opportunities and to automatically and safely conduct the refactorings. ValExtractor+ is composed of two parts, i.e., solutionAdvisor and opportunityAdvisor . Given a to-be-extracted expression, solutionAdvisor leverages lightweight static source code analysis to validate potential side effects of the expression, and to identify expressions that could be extracted together with the selected expression as a single variable without changing the semantics of the program or introducing any new exceptions. The static code analysis significantly improves the safety of automated extraction of local variables. To free programmers from manually selecting to-be-extracted expressions, opportunityAdvisor leverages solutionAdvisor to automatically retrieve all expressions that could be extracted safely as well as their refactoring solutions. It then leverages a learning-based classifier to predict which of the retrieved expressions should be extracted. Evaluations on open-source applications suggest that solutionAdvisor successfully avoided all defects (more than two hundred) caused by extracting local variable refactorings conducted by Eclipse (243 defects) or IntelliJ IDEA (263 defects). Additionally, opportunityAdvisor was able to effectively recommend expressions for extraction, achieving 307 true positives (TP) and 21,121 true negatives (TN). Four pull requests from our work (PR IDs: 66, 333, 439, and 360) were successfully merged into the Eclipse community repository, showcasing the practical impact and robustness of our approach as recognized by the wider developer community.

Natural languages are “natural” in that texts in natural languages are repetitive and predictable. Recent research indicates that programming languages share similar characteristics (naturalness), with source code displaying patterns of repetition and predictability. Notably, studies have shown that buggy code deviates from these natural patterns in that buggy code is significantly less natural than bug-free one. In this article, we conduct a large-scale and extensive empirical study to investigate whether code defects lead to unnaturalness of source code. Different from existing studies, we leverage multiple large-scale and high-quality bug repositories where bug-irrelevant changes in bug-fixing commits have been explicitly excluded. The leveraged software applications cover different programming languages, and the empirical study involves real-world software defects as well as defects injected automatically with well-known mutation operators. On the one side, our evaluation results confirm existing studies in that buggy source code lines are often less natural than bug-free ones. On the other side, our evaluation reveals some interesting new findings. First, fixing bugs does not significantly improve the naturalness of code lines and the fixed lines on average are as unnatural as buggy ones. This finding may suggest that software defects are not the root causes of source code’s unnaturalness although there does existing statistically significant correlation between software defects and source code’s naturalness. Second, defects in different programming languages have similar effect on source code’s naturalness. The conclusions (i.e., buggy code is less natural but fixing the bugs cannot improve source code’s naturalness) hold regardless of the programming languages. Third, injecting defects automatically by well-known mutation operators does not significantly reduce the naturalness of involved source code lines. This suggests that automatically injected defects may have a similar impact on the naturalness of source code as real-world defects inadvertently introduced by developers. Fourth, the detects’ impact on source code’s naturalness varies slightly among different categories of software defects. Although fixing bugs on average does not significantly improve the naturalness of involved source code, fixing “checking” related bugs does significantly improve the naturalness of source code. Finally, locating buggy code lines according to naturalness alone is inaccurate, resulting in extremely low precision (less than one percent).

Open source software (OSS) has been playing a fundamental role in not only information technology but also our social lives. Attracted by various advantages of OSS, increasing commercial companies are participating extensively in open source development, and this has had a broad impact. Enormous research efforts have been devoted to understanding this phenomenon and trying to pursue a win-win result. To characterize the current research achievement and identify challenges, this article provides a comprehensive systematic literature review (SLR) of existing research on company participation in OSS. We collected 105 papers and organized them based on their research topics, which cover three main directions, i.e., participation motivation, contribution model, and impact on OSS development. We found that companies have diverse motivations from economic, technological, and social aspects, and no one study covered all the motivation categories. Existing studies categorize five main companies’ contribution models in OSS projects through their objectives and how they shape OSS communities. Researchers also explored how commercial participation affects OSS development, including companies, developers, and OSS projects. This study contributes to a comprehensive understanding of commercial participation in OSS development. Based on our findings, we present a set of research challenges and promising directions for companies’ better participation in OSS.

Extract local variable is one of the most popular refactorings. It is frequently employed to replace occurrences of a complex expression with simple accesses to a newly introduced variable that is initialized by the original complex expression. Consequently, most IDEs and refactoring tools provide automated support for this refactoring, e.g., to suggest names for the newly extracted variables. However, we find approximately 70% of the names recommended by these IDEs are different from what developers manually constructed, adding additional renaming burdens to developers and providing limited assistance. In this article, we introduce VarNamer , an automated approach designed to recommend variable names for extract local variable refactorings. Through a large-scale empirical study, we identify key contexts, such as variable initializations and homogeneous variables (variables whose initializations are identical to that of the newly extracted variable), that are useful for composing variable names. Leveraging these insights, we developed a set of heuristic rules through program static analysis techniques, e.g., lexical analysis, syntax analysis, control flow analysis, and data flow analysis, and employ data mining techniques, i.e., FP-growth algorithm, to recommend variable names effectively. Notably, some of our heuristic rules have been successfully integrated into Eclipse , where they are now distributed with the latest releases of the IDE. Evaluation of VarNamer on a dataset of 27,158 real-world extract local variable refactorings in Java applications demonstrates its superiority over state-of-the-art IDEs. Specifically, VarNamer significantly increases the chance of exact match by 52.6% compared to Eclipse and 40.7% compared to IntelliJ IDEA . We also evaluated the proposed approach with real-world extract local variable refactorings conducted in C \(++\) projects, and the results suggest that the approach can achieve comparable performance on programming languages besides Java. It may suggest the generalizability of VarNamer . Finally, we designed and conducted a user study to investigate the impact of VarNamer on developers’ productivity. The results of the user study suggest that our approach can speed up the refactoring by 27.8% and reduce 49.3% edits on the recommended variable names.

FPGA (Field Programmable Gate Array) synthesis tools are crucial for hardware development and AI acceleration, and their bugs could compromise hardware reliability and risk downstream applications. However, it remains unknown in understanding the characteristics of these bugs. What are the root causes that trigger bugs in FPGA synthesis tools? What are the characteristics of these bugs? What are the challenges in detecting and addressing them? This paper takes the first step towards answering these questions by conducting a comprehensive study of FPGA synthesis tool bugs. We analyze 551 confirmed bugs in both commercial and open source FPGA synthesis tools, i.e., Vivado, Quartus Prime, and Yosys, covering root causes, symptoms, bug-prone components, fix characteristics, and achieve 17 valuable findings. We find that, on average, around 46.2% of bugs result from HDL (Hardware Description Language) standard noncompliance across the three tools. However, it is hard for current formal validations to fully test HDL standards compliance. Additionally, on average over 25.8% bugs show domain-specific optimization traits due to inappropriate optimization and mapping. Meanwhile, beyond 28% of bugs trigger unexpected behavior without clear signs, making the formulation of effective test oracles challenging. These findings help addressing FPGA synthesis tool bugs and guide further research.

Source code identifiers often contain abbreviations. Such abbreviations may reduce the readability of the source code, which in turn hinders the maintenance of the software applications. To this end, accurate and automated approaches to expanding abbreviations in source code are desirable and abbreviation expansion has been intensively investigated. However, to the best of our knowledge, most existing approaches are heuristics, and none of them has even employed deep learning techniques, let alone the most advanced large language models (LLMs). LLMs have demonstrated cutting-edge performance in various software engineering tasks, and thus it has the potential to expand abbreviations automatically. To this end, in this paper, we present the first empirical study on prompt-based usage of LLMs for abbreviation expansion. Our evaluation results on a public benchmark suggest that GPT is substantially less accurate than the state-of-the-art approach, reducing precision and recall by 28.2% and 27.8%, respectively. We manually analyzed the failed cases, and discovered the root causes for the failures: 1) Lack of contexts and 2) Inability to recognize abbreviations. In response to the first cause, we investigated the effect of various contexts and found surrounding source code is the best selection. In response to the second cause, we designed an iterative approach that identifies and explicitly marks missed abbreviations in prompts. Finally, we propose a post-condition checking to exclude incorrect expansions that violate common sense. All such measures together make LLM-based abbreviation expansion comparable to the state of the art while avoiding expensive source code parsing and deep analysis that are indispensable for state-of-the-art approaches. Our evaluation results on open-source LLMs, i.e., DeepSeek-Coder and Llama, confirm that the post-condition checking works well with various LLMs.

Software developers and maintainers frequently conduct software refactorings to improve software quality. Identifying the conducted software refactorings may significantly facilitate the comprehension of software evolution, and thus facilitate software maintenance and evolution. Besides that, the identified refactorings are also valuable for data-driven approaches in software refactoring. To this end, researchers have proposed a few approaches to identifying software refactorings automatically. However, the performance (especially precision) of such approaches deserves substantial improvement. To this end, in this paper, we propose a novel refactoring detection approach, calledReExtractor+. At the heart ofReExtractor+is a reference-based entity matching algorithm that matches coarse-grained code entities (e.g., classes and methods) between two successive versions, and a context-aware statement matching algorithm that matches statements within a pair of matched methods. We evaluatedReExtractor+on a benchmark consisting of 400 commits from 20 real-world projects. The evaluation results suggested thatReExtractor+significantly outperformed the state of the art in refactoring detection, reducing the number of false positives by 57.4% and improving recall by 18.4%. We also evaluated the performance of the proposed matching algorithms that serve as the cornerstone of refactoring detection. The evaluation results suggested that the proposed algorithms excel in matching code entities, substantially reducing the number of mistakes (false positives plus false negatives) by 67% compared to the state-of-the-art approaches.

Software refactoring is widely conducted in the industry and well-studied in the academic community. There are dozens of software refactoring types, and each type of refactoring often requires its unique tool support and algorithms. Consequently, knowing which types of refactorings are popular in real-world practice and which are less supported by existing tools is highly valuable. To this end, in this paper, we present a large-scale empirical study on software refactorings in real-world open-source Java projects. We first retrieved by keywords 15,860 code commits from GitHub that might contain software refactorings. From the resulting commits, we manually analyzed 1,200 of them and successfully identified 100 types of refactorings from 420 commits. We built a taxonomy for the discovered refactorings, and compared them against the refactoring types supported by state-of-the-art refactoring engines and miners. The comparison results suggest that 61 out of the 100 refactoring types have not yet been explicitly supported by any of the refactoring engines, and any refactoring miners have not explicitly supported 62. The empirical study has identified and revealed 31 under-explored refactorings observed in Java real-world open-source applications but not yet supported by existing refactoring tools. These refactorings may have implications for the development of future tool support and enhancements in the refactoring ecosystem.

Given the well-established merits of open source software (OSS), many profit-oriented companies actively participate in OSS communities, making significant contributions. Existing studies have predominantly focused on several advanced and specific questions regarding this phenomenon, mainly from the companies’ perspective, such as companies’ domination and withdrawal. A more basic and comprehensive understanding is missing, i.e., how OSS developers perceive such corporate engagement. Individual developers, including both volunteers and developers assigned by companies, are directly impacted by and have personal experiences with the consequences of commercial participation in OSS projects. This paper aims to bridge this gap by amplifying the voices of individual developers and providing valuable insights that have the potential to enhance companies’ participation in OSS projects. We conducted a survey involving developers from three OSS projects, i.e., Rust, OpenStack, and the Linux kernel, focusing on their attitudes and expectations regarding corporate involvement. We received 84 meaningful responses and analyzed their open-ended responses through thematic analysis. The results suggest that regardless of whether developers were paid or voluntary contributors, a prevailing attitude emerged – 67.9% of developers expressed a positive view of companies’ participation in OSS. The key idea behind their positive attitudes is perceiving commercial participation as a win-win for both the OSS community and companies. The Rust community remains more neutral when compared with the other two communities. We also surveyed and analyzed developers’ expectations of companies’ better participation, which can shed light on how OSS ecosystems can sustainably evolve with the companies involved.

Developers often manually design a few unit tests for a given method under development. After passing such manually designed tests, however, they usually have to turn to automated test case generation tools like EvoSuite and Randoop for more thorough testing. Although the automatically generated tests may achieve a high coverage, they rarely identify hard-to-detect defects automatically because of the well-known test oracle problem: It is challenging to tell whether the output is correct or incorrect without explicit test oracle (expected output). Consequently, developers should manually select and verify a few suspicious test cases to identify hard-to-detect defects. To this end, in this paper, we propose a novel approach, calledOneMoreTest, to generating and selecting the most suspicious tests for manual verification. Based on a manually designed passed test,OneMoreTestautomatically generates millions of input-output pairs for the method under test (MUT) with mutationbased fuzzing. It then trains an automatically generated neural network to simulate the MUT’s behavior. For new tests automatically generated for the same MUT,OneMoreTestsuggests developers with the topkmost suspicious tests that have the greatest distances between their actual output and estimated output (i.e., network’s output). Our evaluation on real-world faulty methods suggests thatOneMoreTestis accurate. On 70.79% of the involved 178 real-world faulty methods, we can identify the defects by manually verifying only a SINGLE test for each of the methods according toOneMoreTest’s suggestions. Compared against the state of the art,OneMoreTestimproved the precision from 46.63% to 72.62%, and recall from 46.63% to 70.79%.

Online shopping platforms, such as Amazon, offer services to billions of people worldwide. Unlike web search or other search engines, product search engines have their unique characteristics, primarily featuring short queries which are mostly a combination of product attributes and structured product search space. The uniqueness of product search underscores the crucial importance of the query understanding component. However, there are limited studies focusing on exploring this impact within real-world product search engines. In this work, we aim to bridge this gap by conducting a comprehensive study and sharing our year-long journey investigating how the query understanding service impacts Amazon Product Search. Firstly, we explore how query understanding-based ranking features influence the ranking process. Next, we delve into how the query understanding system contributes to understanding the performance of a ranking model. Building on the insights gained from our study on the evaluation of the query understanding-based ranking model, we propose a query understanding-based multi-task learning framework for ranking. We present our studies and investigations on Amazon Search.

Renaming is one of the most popular software refactorings. Although developers may know what the new name should be when they conduct a renaming, it remains valuable for refactoring tools to recommend new names automatically so that developers can simply hit Enter and efficiently accept the recommendation to accomplish the refactoring. Consequently, most IDEs automatically recommend new names for renaming refactorings by default. However, the recommendation made by mainstream IDEs is often incorrect. For example, the precision of IntelliJ IDEA in recommending names for field renamings is as low as 6.3%. To improve the accuracy, in this paper, we propose a context-aware lightweight approach (called CARER) to recommend new names for Java field renamings. Different from mainstream IDEs that rely heavily on initializers and data types of the to-be-renamed fields, CARER exploits both dynamic and static contexts of the renamings as well as naming conventions. We evaluate CARER on 1.1K real-world field renamings discovered from open-source applications. Our evaluation results suggest that CARER can significantly improve the state of the practice in recommending new names for field renamings, improving the precision from 6.30% to 61.15%, and recall from 6.30% to 41.50%. Our evaluation results also suggest that CARER is as efficient as IntelliJ IDEA is, making it suitable to be integrated into IDEs.

High-quality defect repositories are vital in defect detection, localization, and repair. However, existing repositories collected from open-source projects are either small-scale or inadequately labeled and packed. This paper systematically summarizes the programming APIs of system resources (i.e., file, socket, and thread) in Java. Additionally, this paper demonstrates the exceptions that may cause resource leaks in the chained and nested streaming operations. A semi-automatic toolchain is built to improve the efficiency of defect extraction, including automatic building for large legacy Java projects. Accordingly, 1,094 resource leaks were collected from 321 open-source projects on GitHub. This repository, named JLeaks, was built by round-by-round filtering and cross-validation, involving the review of approximately 3,185 commits from hundreds of projects. JLeaks is currently the largest resource leak repository, and each defect in JLeaks is well-labeled and packed, including causes, locations, patches, source files, and compiled bytecode files for 254 defects. We have conducted a detailed analysis of JLeaks for defect distribution, root causes, and fix approaches. We compare JLeaks with two well-known resource leak repositories, and the results show that JLeaks is more informative and complete, with high availability, uniqueness, and consistency. Additionally, we show the usability of JLeaks in two application scenarios. Future studies can leverage our repository to encourage better design and implementation of defect-related algorithms and tools.

It is now commonplace for organizations to pay developers to work on specific open source software (OSS) projects to pursue their business goals. Such paid developers work alongside voluntary contributors, but given the different motivations of these two groups of developers, conflict may arise, which may pose a threat to a project's sustainability. This paper presents an empirical study of paid developers and volunteers in Rust, a popular open source programming language project. Rust is a particularly interesting case given considerable concerns about corporate participation. We compare volunteers and paid developers through contribution characteristics and long-term participation, and solicit volunteers' perceptions on paid developers. We find that core paid developers tend to contribute more frequently; commits contributed by onetime paid developers have bigger sizes; peripheral paid developers implement more features; and being paid plays a positive role in becoming a long-term contributor. We also find that volunteers do have some prejudices against paid developers. This study suggests that the dichotomous view of paid vs. volunteer developers is too simplistic and that further subgroups can be identified. Companies should become more sensitive to how they engage with OSS communities, in certain ways as suggested by this study.

Mobile edge computing(MEC) is an innovative technology that deploys computing resources around the demand side to provide near-request and responsiveness-guaranteed computing and storage services. A major attention paid by related works in this direction is mobility, where mobile traces of both edge users and servers are analyzed and exploited for accommodating offloading and migration requests for computation resources in a highly dynamic MEC environment. Our research in this work suggests that information of user interests, in terms of points of interest (POI), can be exploited in conjunction with mobility as well and proposes a hybrid method for for interest-informed and mobility-aware service migration path selection(HIMS). It synthesizes a trajectory prediction model and user interests prediction one for selecting target servers and reliable service migration paths. Experimental results demonstrate that our approach outperforms traditional methods across multiple performance metrics, especially those with sole input of mobility.

God classes are widely recognized as code smells, significantly impairing the maintainability and readability of source code. However, resolving the identified God classes remains a formidable challenge, and we still lack automated and accurate tools to resolve God classes automatically. To this end, in this paper, we propose a novel approach (called ClassSplitter) to decompose God classes. The key observation behind the proposed approach is that software entities (i.e., methods and fields) that are physically adjacent often have strong semantic correlations and thus have a great chance of being classified into the same class during God class deposition. We validate this hypothesis by analyzing 54 God class decomposition refactorings actually conducted in the wild. According to the observation, we measure the similarity between software entities by exploiting not only traditional code metrics but also their relative physical positions. Based on the similarity, we customize a clustering algorithm to classify the methods within a given God class, and each of the resulting clusters is taken as a new class. Finally, ClassSplitter allocates the fields of the God class to the new classes according to the field-access-based coupling between fields and classes. We evaluate ClassSplitter using 133 real-world God classes from open-source applications. Our evaluation results suggest that ClassSplitter could substantially improve the state of the art in God class decomposition, improving the average MoJoFM by 47%. Manual evaluation also confirmed that in most cases (77%) the solutions suggested by ClassSplitter were preferred by developers to alternatives suggested by the state-of-the-art baseline approach.

Commit classification for maintenance activities is of critical importance for both industry and academia. State-of-the-art approaches either treat code changes as plain text or rely on manually identified features. Directly applying the most advanced model of code change representation into commit classification faces two limitations: (1) coarse-grained diff comparison neglects the distance of modified code lines; (2) missing key context information of hunk modification and file categories. This study proposes a novel classification model, COLARE, which compares code changes at the hunk level, takes fine-grained features based on categories of changed files, and aggregates with the representation of commit messages. The evaluation results show that our model outperforms state-of-the-art techniques by 7.24% and 7.35% in accuracy and macro F1 score, respectively. We also manually labeled a multi-language dataset and evaluated our approach, The results further confirm that our approach achieves the best performance over three baselines, including ChatGPT (3.5). The evaluation of the ablation study demonstrates the effectiveness of the major components in our technique.

Methods should be named to summarize their responsibilities meaningfully. When a method has a non-trivial responsibility, it may require a naming using multiple words. However, overlong method names are susceptible to typos and reduced readability (e.g., displaying a statement partially in standard screen width or splitting it into multiple lines). Programming naming conventions commonly adopt a maximal length (in characters) for identifiers. In practice, developers may not necessarily find a meaningful name that follows such naming conventions when coding a non-trivial method. This article presents the first automated technique (called NameCompressor ) to shorten overlong method names. Our inspiration is that many lengthy words/phrases in an overlong method name have known and unambiguous abbreviations. The use of these abbreviations for method names is common. To shorten an overlong method name, NameCompressor employs three compression techniques, i.e., context-aware compression, probability-based compression, and machine learning-based compression, to find appropriate abbreviations for the words/phrases in the method name. We evaluate NameCompressor on a dataset of 700 overlong method names. It correctly generates 613 short names identical to those specified by the developers of these methods.

Software developers frequently use code completion tools to accelerate software development by suggesting the following code elements. Researchers usually employ AutoRegressive (AR) decoders to complete code sequences in a left-to-right, token-by-token fashion. To improve the accuracy and efficiency of code completion, we argue that tokens within a code statement have the potential to be predicted concurrently. In this article, we first conduct an empirical study to analyze the dependency among the target tokens in line-level code completion. The results suggest that it is potentially practical to generate all statement tokens in parallel. To this end, we introduce SANAR, a simple and effective syntax-aware non-autoregressive model for line-level code completion. To further improve the quality of the generated code, we propose an adaptive and syntax-aware sampling strategy to boost the model’s performance. The experimental results obtained from two widely used datasets indicate that our model outperforms state-of-the-art code completion approaches of similar model size by a considerable margin, and is faster than these models with up to 9× speed-up. Moreover, the extensive results additionally demonstrate that the enhancements achieved by SANAR become even more pronounced with larger model sizes, highlighting their significance.

In [1], the affiliation of the primary authors should be as follows:

Commit messages are critical for code comprehension and software maintenance. Writing a high-quality message requires skill and effort. To support developers and reduce their effort on this task, several approaches have been proposed to automatically generate commit messages. Despite the promising performance reported, we have identified three significant and prevalent threats in these automated approaches: 1) the datasets used to train and evaluate these approaches contain a considerable amount of ‘noise’; 2) current approaches only consider commits of a limited diff size; and 3) current approaches can only generate the subject of a commit message, not the message body. The first limitation may let the models ‘learn’ inappropriate messages in the training stage, and also lead to inflated performance results in their evaluation. The other two threats can considerably weaken the practical usability of these approaches. Further, with the rapid emergence of large language models (LLMs) that show superior performance in many software engineering tasks, it is worth asking: can LLMs address the challenge of long diffs and whole message generation? This article first reports the results of an empirical study to assess the impact of these three threats on the performance of the state-of-the-art auto generators of commit messages. We collected commit data of the Top 1,000 most-starred Java projects in GitHub and systematically removed noisy commits with bot-submitted and meaningless messages. We then compared the performance of four approaches representative of the state-of-the-art before and after the removal of noisy messages, or with different lengths of commit diffs. We also conducted a qualitative survey with developers to investigate their perspectives on simply generating message subjects. Finally, we evaluate the performance of two representative LLMs, namely UniXcoder and ChatGPT, in generating more practical commit messages. The results demonstrate that generating commit messages is of great practical value, considerable work is needed to mature the current state-of-the-art, and LLMs can be an avenue worth trying to address the current limitations. Our analyses provide insights for future work to achieve better performance in practice.

Version control systems are widely used to manage the evolution of software applications. However, such version control systems take source code as lines of plain text, and thus they cannot present the evolution of software entities embedded in the source code. To this end, a few approaches have been proposed to match software entities before and after a given commit, known as software entity matching algorithms. However, the accuracy of such algorithms requires further improvement. In this paper, we propose an automated iterative algorithm (called ReMapper) to match software entities between two successive versions. The key insight of ReMapper is that the qualified name, the implementation, and the references of a software entity together can distinguish it from others. It matches software entities iteratively because the mapping depends on the reference-based similarity whereas the reference-based similarity depends on the mapping of entities as well. We evaluated ReMapper on a benchmark consisting of 215 commits from 21 real-world projects. Our evaluation results suggest that ReMapper substantially outperformed the state of the art, reducing the number of mistakes (false positives plus false negatives) substantially by 85.8%. We also evaluated to what extent it may improve the automated refactoring discovery (mining) that relies heavily on automated entity matching. Our evaluation results suggest that it substantially improved the state of the art in refactoring discovery, improving recall by 6.9% and reducing the number of false positives by 72.6%.

Creativity focuses on the generation of novel and useful ideas. In this paper, we propose an approach to automatically generating creative requirements candidates via the adversarial examples resulted from applying small changes (perturbations) to the original requirements descriptions. We present an architecture where the perturbator and the classifier positively influence each other. Meanwhile, we ensure that each adversarial example is uniquely traceable to an existing feature of the software, instrumenting explainability. Our experimental evaluation of six datasets shows that around 20% adversarial shift rate is achievable. In addition, a human subject study demonstrates our results are more clear, novel, and useful than the requirements candidates outputted from a state-of-the-art machine learning method. To connect the creative requirements closer with software development, we collaborate with a software development team and show how our results can support behavior-driven development for a web app built by the team.

To port the Linux distributions to a new Instruction Set Architecture (ISA), developers have to rebuild the software packages of the distributions.The complex dependencies of the software packages bring a great challenge.It is important to understand and properly handle the dependencies.We selected Fedora, a typical Linux distribution, and studied the dependencies within the software repositories of aarch64 and x86_64 architecture.We proposed a package dependency network framework to study the roles played by different packages.We obtained three network dependency patterns and proposed the corresponding division strategies which help developer build the source packages in parallel.Our study reveals that the key packages located at the root of multiple dependency chains significantly impact the division of the network, and their builds should be prioritized.Meanwhile, some packages with external dependencies can be temporarily masked to make a sub-network independent.Furthermore, the network dependency patterns are also observed in Fedora 33 riscv64 and OpenEuler riscv64.Our findings can help researchers have a better knowledge of Linux distribution dependency network and help practitioners conduct efficient package builds.

Extract local variable is a well-known and widely used refactoring. It is frequently employed to replace one or more occurrences of a complex expression with simple accesses to a newly added variable. Although most IDEs provide tool support for extract local variables, such tools without deep analysis of the refactorings may result in semantic errors. To this end, in this paper, we propose a novel and more reliable approach, called ValExtractor, to conduct extract variable refactorings automatically. The major challenge of automated extract local variable refactorings is how to efficiently and accurately identify the side effect of the extracted expressions and the potential interaction between the extracted expressions and their contexts without time-consuming dynamic execution of the involved programs. To resolve this challenge, ValExtractor leverages a lightweight static source code analysis to validate the side effect of the selected expression, and to identify which occurrences of the selected expression could be extracted together without changing the semantics of the program or introducing potential new exceptions. Our evaluation results on open-source Java applications suggest that Eclipse and IntelliJ IDEA, the state-of-the-practice refactoring engines, resulted in a large number of faulty extract variable refactorings whereas ValExtractor successfully avoided all such errors. The proposed approach has been merged into (and distributed with) Eclipse to improve the safety of extract local variable refactoring.

Feature envy is one of the well-recognized code smells that should be removed by software refactoring. A major challenge in feature envy detection is that traditional approaches are less accurate whereas deep learning-based approaches are suffering from the lack of high-quality large-scale training data. Although existing refactoring detection tools could be employed to discover real-world feature envy examples, the noise (i.e., false positives) within the resulting data could significantly influence the quality of the training data as well as the performance of the models trained on the data. To this end, in this paper, we propose a sequence of heuristic rules and a decision tree-based classifier to filter out false positives reported by state-of-the-art refactoring detection tools. The data after filtering serve as the positive items in the requested training data. From the same subject projects, we randomly select methods that are different from positive items as negative items. With the real-world examples (both positive and negative examples), we design and train a deep learning-based binary model to predict whether a given method should be moved to a potential target class. Different from existing models, it leverages additional features, i.e., coupling between methods and classes (CBMC) and the message passing coupling between methods and classes (MCMC) that have not yet been exploited by existing approaches. Our evaluation results on real-world open-source projects suggest that the proposed approach substantially outperforms the state of the art in feature envy detection, improving precision and recall by 38.5% and 20.8%, respectively.

Bug-related research, e.g., fault localization, program repair, and software testing, relies heavily on high-quality and large-scale software bug repositories. The importance of such repositories is twofold. On one side, real-world bugs and their associated patches may inspire novel approaches for finding, locating, and repairing software bugs. On the other side, the real-world bugs and their patches are indispensable for rigorous and meaningful evaluation of approaches to software testing, fault localization, and program repair. To this end, a number of software bug repositories, e.g., iBUGS and Defects4J, have been constructed recently by mining version control systems and bug tracking systems. However, fully automated construction of bug repositories by simply taking bug-fixing commits from version control systems often results in inaccurate patches that contain many bug-irrelevant changes. Although we may request experts or developers to manually exclude the bug-irrelevant changes (as the authors of Defects4J did), such extensive human intervention makes it difficult to build large-scale bug repositories. To this end, in this paper, we propose an automatic approach, calledBugBuilder, to construct bug repositories from version control systems. Different from existing approaches, it automatically extracts complete and concise bug-fixing patches and excludes bug-irrelevant changes. It first detects and excludes software refactorings involved in bug-fixing commits.BugBuilderthen enumerates all subsets of the remaining part, and discards invalid subsets by compilation and software testing. If exactly a single subset survives the validation, this subset is taken as the complete and concise bug-fixing patch for the associated bug. In case multiple subsets survive, BugBuilder employs a sequence of heuristics to select the most likely one. Evaluation results on 809 real-world bug-fixing commits in Defects4J suggest thatBugBuildersuccessfully extracted complete and concise bug-fixing patches from forty-three percent of the bug-fixing commits, and its precision (99%) was even higher than human experts. We also built a bug repository, called GrowingBugs, with the proposed approach. The resulting repository serves as evidence of the usefulness of the proposed approach, as well as a publicly available benchmark for bug-related research.

In programming courses, providing students with concise and constructive feedback on faulty submissions (programs) is highly desirable. However, providing feedback manually is often time-consuming and tedious. To release tutors from the manual construction of concise feedback, researchers have proposed approaches such asCLARAandRefactoryto construct feedback automatically. The key to such approaches is to fix a faulty program by making it equivalent to one of its correct reference programs whose overall structure is identical to that of the faulty submission. However, for a newly released assignment, it is likely that there are no correct reference programs at all, let alone correct reference programs sharing identical structure with the faulty submission. Therefore, in this paper, we proposeAssignmentMendergenerating concise patches for newly released assignments. The key insight ofAssignmentMenderis that a faulty submission can be repaired by reusing fine-grained code snippets from submissions (even when they are faulty) for the same assignment. It automatically locates suspicious code in the faulty program and leverages static analysis to retrieve reference code from existing submissions with a graph-based matching algorithm. Finally, it generates candidate patches by modifying the suspicious code based on the reference code. Different from existing approaches,AssignmentMenderexploits faulty submissions in addition to bug-free submissions to generate patches. Another advantage ofAssignmentMenderis that it can leverage submissions whose overall structures are different from those of the to-be-fixed submission. Evaluation results on 128 faulty submissions from 10 assignments show thatAssignmentMenderimproves the state-of-the-art in feedback generation for newly released assignments. A case study involving 40 students and 80 submissions further provides initial evidence showing that the proposed approach is useful in practice.

A key issue in collaborative software development is communication among developers. One modality of communication is a commit message, in which developers describe the changes they make in a repository. As such, commit messages serve as an "audit trail" by which developers can understand how the source code of a project has changed---and why. Hence, the quality of commit messages affects the effectiveness of communication among developers. Commit messages are often of poor quality as developers lack time and motivation to craft a good message. Several automatic approaches have been proposed to generate commit messages. However, these are based on uncurated datasets including considerable proportions of poorly phrased commit messages. In this multi-method study, we first define what constitutes a "good" commit message, and then establish what proportion of commit messages lack information using a sample of almost 1,600 messages from five highly active open source projects. We find that an average of circa 44% of messages could be improved, suggesting the use of uncurated datasets may be a major threat when commit message generators are trained with such data. We also observe that prior work has not considered semantics of commit messages, and there is surprisingly little guidance available for writing good commit messages. To that end, we develop a taxonomy based on recurring patterns in commit messages' expressions. Finally, we investigate whether "good" commit messages can be automatically identified; such automation could prompt developers to write better commit messages.

Texts in natural languages are highly repetitive and predictable because of the naturalness of natural languages. Recent research validated that source code in programming languages is also repetitive and predictable, and naturalness is an inherent property of source code. It was also reported that buggy code is significantly less natural than bug-free one, and bug fixing substantially improves the naturalness of the involved source code. In this paper, we revisit the naturalness of buggy code and investigate the effect of bug-fixing on the naturalness of source code. Different from the existing investigation, we leverage two large-scale and high-quality bug repositories where bug-irrelevant changes in bug-fixing commits have been explicitly excluded. Our evaluation results confirm that buggy lines are often less natural than bug-free ones. However, fixing bugs could not significantly improve the naturalness of involved code lines. Fixed lines on average are as unnatural as buggy ones. Consequently, bugs are not the root cause of the unnaturalness of source code, and it could be inaccurate to identify buggy code lines solely by the naturalness of source code. Our evaluation results suggest that the naturalness-based buggy line detection results in extremely low precision (less than one percentage).

Corporate participation plays an increasing role in Open Source Software (OSS) development. Unlike volunteers in OSS projects, companies are driven by business objectives. To pursue corporate interests, companies may try to dominate the development direction of OSS projects. One company's domination in OSS may 'crowd out' other contributors, changing the nature of the project, and jeopardizing the sustainability of the OSS ecosystem. Prior studies of corporate involvement in OSS have primarily focused on predominately positive aspects such as business strategies, contribution models, and collaboration patterns. However, there is a scarcity of research on the potential drawbacks of corporate engagement. In this paper, we investigate corporate dominance in OSS ecosystems. We draw on the field of Economics and quantify company domination using a dominance measure; we investigate the prevalence, patterns, and impact of domination in the evolution of the OpenStack ecosystem. We find evidence of company domination in over 73% of the repositories in OpenStack, and approximately 25% of companies dominate one or more repositories per version. We identify five patterns of corporate dominance: Early incubation, Full-time hosting, Growing domination, Occasional domination, and Last remaining. We find that domination has a significantly negative relationship with the survival probability of OSS projects. This study provides insights for building sustainable relationships between companies and the OSS ecosystems in which they seek to get involved.

To achieve commercial goals, companies have made substantial contributions to large open-source software (OSS) ecosystems such as OpenStack and have become the main contributors. However, they often withdraw their employees for a variety of reasons, which may affect the sustainability of OSS projects. While the turnover of individual contributors has been extensively investigated, there is a lack of knowledge about the nature of companies’ withdrawal. To this end, we conduct a mixed-methods empirical study on OpenStack to reveal how common company withdrawals were, to what degree withdrawn companies made contributions, and what the rationale behind withdrawals was. By analyzing the commit data of 18 versions of OpenStack, we find that the number of companies that have left is increasing and even surpasses the number of companies that have joined in later versions. Approximately 12% of the companies in each version have exited by the next version. Compared to the sustaining companies that joined in the same version, the withdrawn companies tend to have a weaker contribution intensity but contribute to a similar scope of repositories in OpenStack. Through conducting a developer survey, we find four aspects of reasons for companies’ withdrawal from OpenStack: company, community, developer, and project. The most common reasons lie in the company aspect, i.e., the company either achieved its goals or failed to do so. By fitting the survival analysis model, we find that commercial goals are associated with the probability of the company’s withdrawal, and that a company’s contribution intensity and scale are positively correlated with its retention. Maintaining good retention is important but challenging for OSS ecosystems, and our results may shed light on potential approaches to improve company retention and reduce the negative impact of company withdrawal.

Although the negative impact of abbreviations in source code is well-recognized, abbreviations are common for various reasons. To this end, a number of approaches have been proposed to expand abbreviations in identifiers. However, such approaches are either inaccurate or confined to specific identifiers. To this end, in this paper, we propose a generic and accurate approach to expand identifier abbreviations by leveraging both semantic relation and transfer expansion. One of the key insights of the approach is that abbreviations in the name of software entity$e$have a great chance to find their full terms in names of software entities that are semantically related to$e$. Consequently, the proposed approach builds a knowledge graph to represent such entities and their relationships with$e$and searches the graph for full terms. Another key insight is that literally identical abbreviations within the same application are likely (but not necessary) to have identical expansions, and thus the semantics-based expansion in one place may be transferred to other places. To investigate when abbreviation expansion could be transferred safely, we conduct a case study on three open-source applications. The results suggest that a significant part (75 percent) of expansions could be transferred among lexically identical abbreviations within the same application. However, the risk of transfer varies according to various factors, e.g., length of abbreviations, the physical distance between abbreviations, and semantic relations between abbreviations. Based on these findings, we design nine heuristics for transfer expansion and propose a learning-based approach to prioritize both transfer heuristics and semantic-based expansion heuristics. Evaluation results on nine open-source applications suggest that the proposed approach significantly improves the state of the art, improving recall from 29 to 89 percent and precision from 39 to 92 percent.

Code completion is to predict the rest of a statement a developer is typing. Although advanced code completion approaches have greatly improved the accuracy of code completion in modern IDEs, it remains challenging to predict project-specific API method invocations or field accesses because little knowledge about such elements could be learned in advance. To this end, in this paper we propose an accurate approach called HeeNAMA to suggesting the next project-specific API member access. HeeNAMA focuses on a specific but common case of code completion: suggesting the following member access whenever a project-specific API instance is followed by a dot on the right hand side of an assignment. By focusing on such a specific case, HeeNAMA can take full advantages of the context of the code completion, including the type of the left hand side expression of the assignment, the identifier on the left hand side, the type of the base instance, and similar assignments typed in before. All such information together enables highly accurate code completion. Given an incomplete assignment, HeeNAMA generates the initial candidate set according to the type of the base instance, and excludes those candidates that are not type compatible with the left hand side of the assignment. If the enclosing project contains assignments highly similar to the incomplete assignment, it makes suggestions based on such assignments. Otherwise, it selects the one from the initial candidate set that has the greatest lexical similarity with the left hand side of the assignment. Finally, it employs a neural network to filter out risky predictions, which guarantees high precision. Evaluation results on open-source applications suggest that compared to the state-of-the-art approaches and the state-of-the-practice tools HeeNAMA improves precision and recall by 70.68 and 25.23 percent, relatively.

To release developers from time-consuming software development, many approaches have been proposed to generate source code automatically according to software requirements. With significant advances in deep learning and natural language processing, deep learning-based approaches are proposed to generate source code from natural language descriptions. The key insight is that given a large corpus of software requirements and their corresponding implementations, advanced deep learning techniques may learn how to translate software requirements into source code that fulfill such requirements. Although such approaches are reported to be highly accurate, they are evaluated on datasets that are rather small, lack of diversity, and significantly different from real-world software requirements. To this end, we build a large scale dataset that is composed of longer requirements as well as validated implementations. We evaluate the state-of-the-art approaches on this new dataset, and the results suggest that their performance on our dataset is significantly lower than that on existing datasets concerning the common metrics, i.e., BLEU. Evaluation results also suggest that the generated programs often contain syntactic and semantical errors, and none of them can pass even a single predefined test case. Further analysis reveals that the state-of-the-art approaches learn little from software requirements, and most of the successfully generated statements are popular statements in the training programs. Based on this finding, we propose a popularity-based approach that always generates the most popular statements in training programs regardless of the input (software requirements). Evaluation results suggest that none of the state-of-the-art approaches can outperform this simple statistics-based approach. As a conclusion, deep learning-based program generation requires significant improvement in the future, and our dataset may serve as a basis for future research in this direction.

Methods are basic elements for functional organization in software applications. A high-quality method name should clearly express its function, and help developers understand its usages quickly without reading through the lengthy and complex method body. However, in some cases, method names could be inconsistent with their functional implementations. The inconsistency in turn may result in inaccurate interpretation of methods, and even buggy method invocations. To this end, in this paper, we propose a deep learning-based approach, called NameChecker, to detecting the inconsistency between method names and their corresponding method bodies. NameChecker extracts lexical and structural features of source code by static code analysis. Based on the extracted features, NameChecker employs deep learning techniques (i.e., LSTM, and Attention mechanism) to predict whether the given method name is consistent with its implementation. Different from other deep learning based approaches to inconsistency detection, NameChecker avoids the generation (recommendation) of method names. Empirical studies suggested that generated method names are often incorrect, and thus avoiding method name generation may significantly improve the accuracy of NameChecker. We evaluate NameChecker on open-source applications, and our evaluation results suggest that NameChecker improves the state of the art by increasing the F1-score from 66.7% to 73.4%.

Defect prediction forecasts defect proneness or the number of defects contained in software systems. It is frequently employed to efficiently prioritize and allocate the limited testing resources to the modules that are more likely to be defective during the process of software development and maintenance. Consequently, a number of defect prediction approaches have been proposed. Most of the existing approaches on defect prediction regard defect prediction as a classification problem in which programs are classified as buggy or non-buggy. However, identifying the defect proneness of a given software module is not sufficient in practical software testing. The research on predicting the number of defects is limited and the performances of these approaches are constantly being optimized and improved. Therefore, in this paper, we propose a novel approach that leverages a convolutional neural network to predict the number of defects in software systems automatically. First, we preprocess the PROMISE dataset, which involves performing natural logarithm transformation and data normalization. Second, we feed the preprocessed dataset to a specially designed convolutional neural network-based model to predict the number of defects. Third, we rank the software modules according to the corresponding predicted number of defects in descending order. We also evaluate the proposed approach on a well-known dataset by cross-validation. The evaluation results suggest that the proposed approach is both accurate and robust, and it improves the state of the art. On average, it significantly improves the Kendall correlation coefficient by 16% and the fault-percentile-average by 4%.

High-quality and large-scale repositories of real bugs and their concise patches collected from real-world applications are critical for research in software engineering community. In such a repository, each real bug is explicitly associated with its fix. Therefore, on one side, the real bugs and their fixes may inspire novel approaches for finding, locating, and repairing software bugs; on the other side, the real bugs and their fixes are indispensable for rigorous and meaningful evaluation of approaches for software testing, fault localization, and program repair. To this end, a number of such repositories, e.g., Defects4J, have been proposed. However, such repositories are rather small because their construction involves expensive human intervention. Although bug-fixing code commits as well as associated test cases could be retrieved from version control systems automatically, existing approaches could not yet automatically extract concise bug-fixing patches from bug-fixing commits because such commits often involve bug-irrelevant changes. In this paper, we propose an automatic approach, called BugBuilder, to extracting complete and concise bug-fixing patches from human-written patches in version control systems. It excludes refactorings by detecting refactorings involved in bug-fixing commits, and reapplying detected refactorings on the faulty version. It enumerates all subsets of the remaining part and validates them on test cases. If none of the subsets has the potential to be a complete bug-fixing patch, the remaining part as a whole is taken as a complete and concise bug-fixing patch. Evaluation results on 809 real bug-fixing commits in Defects4J suggest that BugBuilder successfully generated complete and concise bug-fixing patches for forty percent of the bug-fixing commits, and its precision (99%) was even higher than human experts.

Abstractions are significant domain terms that have assisted in requirements elicitation and modeling. To extend the assistance towards requirements validation, we present in this paper an automated approach to identifying the abstractions for supporting requirements-based testing. We select relevant Wikipedia pages to serve as a domain corpus that is independent from any specific software system. We further define five novel patterns based on part-of-speech tagging and dependency parsing, and frame our candidate abstractions in the form ofpairs for better testability. We evaluate our approach with six software systems in two application domains: Electronic health records and Web conferencing. The results show that our abstractions are more accurate than those generated by two of the state-of-the-art techniques. Initial findings also indicate our abstractions’ capabilities of revealing bugs and matching the environmental assumptions created manually.

Abbreviations are common in source code. Properly designed abbreviations may significantly facilitate typing, typesetting, and reading of lengthy source code. However, abbreviations, if used improperly, may also significantly reduce the readability and maintainability of source code. Although a few automated approaches have been proposed to suggest full terms for given abbreviations, to the best of our knowledge, there is no automated approaches to suggest whether abbreviations are used properly, i.e., whether they should be replaced with corresponding full terms. Notably, it is often challenging for inexperienced developers and maintainers to make such decisions. To this end, in this paper, we propose an automated approach to assisting developers and maintainers in making the decisions. The rationale of the approach is that abbreviations should not be expanded if the expansion would result in unacceptably lengthy identifiers or if developers/maintainers can easily figure out the meaning (full terms) of the abbreviations based on their domain knowledge or contexts of the abbreviations. From a corpus of programs, we leverage data mining techniques to discover common abbreviations that are frequently employed by various developers in similar contexts. The key of the data mining is to turn the problem of mining common abbreviations into the maximal clique problem that has been extensively studied. We suggest to not expand given abbreviation if it matches at least one of the discovered common abbreviations. From the same corpus, we also calculate the probability distribution for the length of different types of identifier, e.g., variable names and method names. The probability distribution specifies how likely an identifier of type T is composed of exactly n characters. Our heuristic is to not expand the abbreviation if the probability of its enclosing identifier would be reduced by the expansion. Finally, we also suggest to not expand the abbreviation if its full terms are contained in surrounding contexts of the abbreviation, i.e., tokens on the same source code line. Other abbreviations that do not receive suggestions from the proposed approach are expected to be replaced with their full terms. Our evaluation results on 1,818 abbreviations from five open-source applications suggest that the proposed approach is accurate with a high accuracy of 95%.

With the increasing number of software bugs, bug fixing plays an important role in software development and maintenance. To improve the efficiency of bug resolution, developers utilize bug reports to resolve given bugs. Especially, bug triagers usually depend on bugs' descriptions to suggest priority levels for reported bugs. However, manual priority assignment is a time-consuming and cumbersome task. To resolve this problem, recent studies have proposed many approaches to automatically predict the priority levels for the reported bugs. Unfortunately, these approaches still face two challenges that include words' nonconsecutive semantics in bug reports and the imbalanced data. In this article, we propose a novel approach that graph convolutional networks (GCN) based on weighted loss function to perform the priority prediction for bug reports. For the first challenge, we build a heterogeneous text graph for bug reports and apply GCN to extract words' semantics in bug reports. For the second challenge, we construct a weighted loss function in the training phase. We conduct the priority prediction on four open-source projects, including Mozilla, Eclipse, Netbeans, and GNU compiler collection. Experimental results show that our method outperforms two baseline approaches in terms of the F-measure by weighted average of 13.22%.

Code smells are structures in the source code that suggest the possibility of refactorings. Consequently, developers may identify refactoring opportunities by detecting code smells. However, manual identification of code smells is challenging and tedious. To this end, a number of approaches have been proposed to identify code smells automatically or semi-automatically. Most of such approaches rely on manually designed heuristics to map manually selected source code metrics into predictions. However, it is challenging to manually select the best features. It is also difficult to manually construct the optimal heuristics. To this end, in this paper we propose a deep learning based novel approach to detecting code smells. The key insight is that deep neural networks and advanced deep learning techniques could automatically select features of source code for code smell detection, and could automatically build the complex mapping between such features and predictions. A big challenge for deep learning based smell detection is that deep learning often requires a large number of labeled training data (to tune a large number of parameters within the employed deep neural network) whereas existing datasets for code smell detection are rather small. To this end, we propose an automatic approach to generating labeled training data for the neural network based classifier, which does not require any human intervention. As an initial try, we apply the proposed approach to four common and well-known code smells, i.e., feature envy, long method, large class, and misplaced class. Evaluation results on open-source applications suggest that the proposed approach significantly improves the state-of-the-art.

The location of compilation errors are usually reported by compilers to facilitate quick fixing of such compiler errors. However, sometimes such location information could be incorrect or misleading, which significantly reduces the chance of quick fixing. To this end, in this paper, we propose an automated approach, called iMiLi, to identify misleading location information in compiler diagnoses. We generate potentially illegal programs (called mutants) by mutating legal programs, and compile such mutants. If the compiler generates error diagnoses on a mutant, we extract the location information from the resulting diagnoses. The location information is suspicious if it does not point to the source code where the associated mutation is conducted. Then we propose heuristics for each kind of mutation operators to exclude such suspicious but correct location information. We evaluate the proposed approach on a state-of-the-practice compiler (i.e., Eclipse Compiler for Java, known as ECJ). iMiLi successfully identifies seven categories of incorrect/misleading location information in diagnoses of ECJ.

When users encounter problems with mobile apps, they may commit such problems to developers as bug reports. To facilitate the processing of bug reports, researchers proposed approaches to validate the reported issues automatically according to the steps to reproduce specified in bug reports. Although such approaches have achieved high success rate in reproducing the reported issues, they often rely on a predefined vocabulary to identify and classify actions in bug reports. However, such manually constructed vocabulary and classification have significant limitations. It is challenging for the vocabulary to cover all potential action words because users may describe the same action with different words. Besides that, classification of actions solely based on the action words could be inaccurate because the same action word, appearing in different contexts, may have different meaning and thus belongs to different action categories. To this end, in this paper we propose an automated approach, called MaCa, to identify and classify action words in Mobile apps’ bug reports. For a given bug report, it first identifies action words based on natural language processing. For each of the resulting action words, MaCa extracts its contexts, i.e., its enclosing segment, the associated UI target, and the type of its target element by both natural language processing and static analysis of the associated app. The action word and its contexts are then fed into a machine learning based classifier that predicts the category of the given action word in the given context. To train the classifier, we manually labelled 1,202 actions words from 525 bug reports that are associated with 207 apps. Our evaluation results on manually labelled data suggested that MaCa was accurate with high accuracy varying from 95% to 96.7%. We also investigated to what extent MaCa could further improve existing approaches (i.e., Yakusu and ReCDroid) in reproducing bug reports. Our evaluation results suggested that integrating MaCa into existing approaches significantly improved the success rates of ReCDroid and Yakusu by 22.7% = (69.2%-56.4%)/56.4% and 22.9%= (62.7%-51%)/51%, respectively.

Identifiers in source code are composed of terms in natural languages. Such terms, as well as phrases composed of such terms, convey rich semantics that could be exploited for program analysis and comprehension. To this end, in this paper we propose a deep learning based approach, called MLDetector, to identifying suspicious return statements by leveraging semantics conveyed by the natural language phrases that are used as identifiers in the source code. We specially design a deep neural network to tell whether a given return statement matches its corresponding method signature. The rationale is that both method signature and return value should explicitly specify the output of the method, and thus a significant mismatch between method signature and return value may suggest a suspicious return statement. To address the challenge of lacking negative training data, i.e., incorrect return statements, we generate negative training data automatically by transforming real-world correct return statements. To feed code into neural network, we convert them into vectors by Word2Vec, an unsupervised neural network based learning algorithm. We evaluate the proposed approach in two parts. In the first part, we evaluate it on 500 open-source applications by automatically generating labeled training data. Results suggest that the precision of the proposed approach varies from 83% to 90%. In the second part, we conduct a case study on 100 real-world applications. Evaluation results suggest that 42 out of 65 real-world incorrect return statements are detected (with precision of 59%).

Software systems often receive a large number of bug reports. Triagers read through such reports and assign different priorities to different reports so that important and urgent bugs could be fixed on time. However, manual prioritization is tedious and time-consuming. To this end, in this article, we propose a convolutional neural network (CNN) based automatic approach to predict the multiclass priority for bug reports. First, we apply natural language processing (NLP) techniques to preprocess textual information of bug reports and covert the textual information into vectors based on the syntactic and semantic relationship of words within each bug report. Second, we perform the software engineering domain specific emotion analysis on bug reports and compute the emotion value for each of them using a software engineering domain repository. Finally, we train a CNN-based classifier that generates a suggested priority based on its input, i.e., vectored textual information and emotion values. To the best of our knowledge, it is the first CNN-based approach to bug report prioritization. We evaluate the proposed approach on open-source projects. Results of our cross-project evaluation suggest that the proposed approach significantly outperforms the state-of-the-art approaches and improves the average F1-score by more than 24%.

Abbreviations are widely used in identifiers. However, they have severe negative impact on program comprehension and IR-based software maintenance activities, e.g., concept location, software clustering, and recovery of traceability links. Consequently, a number of efficient approaches have been proposed successfully to expand abbreviations in identifiers. Most of such approaches rely heavily on dictionaries, and rarely exploit the specific and fine-grained context of identifiers. As a result, such approaches are less accurate in expanding abbreviations (especially short ones) that may match multiple dictionary words. To this end, in this paper we propose an automatic approach to improve the accuracy of abbreviation expansion by exploiting the specific and fine-grained context. It focuses on a special but common category of abbreviations (abbreviations in parameter names), and thus it can exploit the specific and fine-grained context, i.e., the type of the enclosing parameter as well the corresponding formal (or actual) parameter name. The recent empirical study on parameters suggest that actual parameters are often lexically similar to their corresponding formal parameters. Consequently, it is likely that an abbreviation in a formal parameter can find its full terms in the corresponding actual parameter, and vice versa. Based on this assumption, a series of heuristics are proposed to look for full terms from the corresponding actual (or formal) parameter names. To the best of our knowledge, we are the first to expand abbreviations by exploiting the lexical similarity between actual and formal parameters. We also search for full terms in the data type of the enclosing parameter. Only if all such heuristics fail, the approach turns to the traditional abbreviation dictionaries. We evaluate the proposed approach on seven well known open-source projects. Evaluation results suggest that when only parameter abbreviations are involved, the proposed approach can improve the precision from 26 to 95 percent and recall from 26 to 65 percent compared against the state-of-the-art general purpose approach. Consequently, the proposed approach could be employed as a useful supplement to existing approaches to expand parameter abbreviations.

Presents corrections to author information in the above named paper.

The rapid development of mobile communication technologies prompts the emergence of mobile edge computing (MEC). As the key technology toward 5th generation (5G) wireless networks, it allows mobile users to offload their computational tasks to nearby servers deployed in base stations to alleviate the shortage of mobile resource. Nevertheless, various challenges, especially the edge-user-allocation problem, are yet to be properly addressed. Traditional studies consider this problem as a static global optimization problem where user positions are considered to be time-invariant and user-mobility-related information is not fully exploited. In reality, however, edge users are usually with high mobility and time-varying positions, which usually result in users reallocations among different base stations and impact on user-perceived quality-of-service (QoS). To overcome the above limitations, we consider the edge user allocation problem as an online decision-making and evolvable process and develop a mobility-aware and migration-enabled approach, named MobMig, for allocating users at real-time. Experiments based on real-world MEC dataset clearly demonstrate that our approach achieves higher user coverage rate and lower reallocations than traditional ones.

High quality method names are critical for the readability and maintainability of programs. However, constructing concise and consistent method names is often challenging, especially for inexperienced developers. To this end, advanced machine learning techniques have been recently leveraged to recommend method names automatically for given method bodies/implementation. Recent large-scale evaluations also suggest that such approaches are accurate. However, little is known about where and why such approaches work or don't work. To figure out the state of the art as well as the rationale for the success/failure, in this paper we conduct an empirical study on the state-of-the-art approach code2vec. We assess code2vec on a new dataset with more realistic settings. Our evaluation results suggest that although switching to new dataset does not significantly influence the performance, more realistic settings do significantly reduce the performance of code2vec. Further analysis on the successfully recommended method names also reveals the following findings: 1) around half (48.3%) of the accepted recommendations are made on getter/setter methods; 2) a large portion (19.2%) of the successfully recommended method names could be copied from the given bodies. To further validate its usefulness, we ask developers to manually score the difficulty in naming methods they developed. Code2vec is then applied to such manually scored methods to evaluate how often it works in need. Our evaluation results suggest that code2vec rarely works when it is really needed. Finally, to intuitively reveal the state of the art and to investigate the possibility of designing simple and straightforward alternative approaches, we propose a heuristics based approach to recommending method names. Evaluation results on large-scale dataset suggest that this simple heuristics-based approach significantly outperforms the state-of-the-art machine learning based approach, improving precision and recall by 65.25% and 22.45%, respectively. The comparison suggests that machine learning based recommendation of method names may still have a long way to go.

During software evolution, developers often receive new requirements expressed as feature requests. To implement the requested features, developers have to perform necessary modifications (refactorings) to prepare for new adaptation that accommodates the new requirements. Software refactoring is a well-known technique that has been extensively used to improve software quality such as maintainability and extensibility. However, it is often challenging to determine which kind of refactorings should be applied. Consequently, several approaches based on various heuristics have been proposed to recommend refactorings. However, there is still lack of automated support to recommend refactorings given a feature request. To this end, in this paper, we propose a novel approach that recommends refactorings based on the history of the previously requested features and applied refactorings. First, we exploit the stateof-the-art refactoring detection tools to identify the previous refactorings applied to implement the past feature requests. Second, we train a machine classifier with the history data of the feature requests and refactorings applied on the commits that implemented the corresponding feature requests. The machine classifier is then used to predict refactorings for new feature requests. We evaluate the proposed approach on the dataset of 43 open source Java projects and the results suggest that the proposed approach can accurately recommend refactorings (average precision 73%).

Identifiers account for 70% of source code in terms of characters, and thus the quality of such identifiers is critical for program comprehension and software maintenance. For various reasons, however, many identifiers contain abbreviations, which reduces the readability and maintainability of source code. To this end, a number of approaches have been proposed to expand abbreviations in identifiers. However, such approaches are either inaccurate or confined to specific identifiers. To this end, in this paper we propose a generic and accurate approach to expand identifier abbreviations. The key insight of the approach is that abbreviations in the name of software entity e have great chance to find their full terms in names of software entities that are semantically related to e. Consequently, the proposed approach builds a knowledge graph to represent such entities and their relationships with e, and searches the graph for full terms. The optimal searching strategy for the graph could be learned automatically from a corpus of manually expanded abbreviations. We evaluate the proposed approach on nine well known open-source projects. Results of our k-fold evaluation suggest that the proposed approach improves the state of the art. It improves precision significantly from 29% to 85%, and recall from 29% to 77%. Evaluation results also suggest that the proposed generic approach is even better than the state-of-the-art parameter-specific approach in expanding parameter abbreviations, improving F1 score significantly from 75% to 87%.

Software refactoring is widely employed to improve software quality. A key step in software refactoring is to identify which part of the software should be refactored. To facilitate the identification, a number of approaches have been proposed to identify certain structures in the code (called code smells) that suggest the possibility of refactoring. Most of such approaches rely on manually designed heuristics to map manually selected source code metrics to predictions. However, it is challenging to manually select the best features, especially textual features. It is also difficult to manually construct the optimal heuristics. To this end, in this paper we propose a deep learning based novel approach to detecting feature envy, one of the most common code smells. The key insight is that deep neural networks and advanced deep learning techniques could automatically select features (especially textual features) of source code for feature envy detection, and could automatically build the complex mapping between such features and predictions. We also propose an automatic approach to generating labeled training data for the neural network based classifier, which does not require any human intervention. Evaluation results on open-source applications suggest that the proposed approach significantly improves the state-of-the-art in both detecting feature envy smells and recommending destinations for identified smelly methods.

Requirements traceability provides critical support throughout all phases of software engineering. Automated tracing based on information retrieval (IR) reduces the effort required to perform a manual trace. Unfortunately, IR-based trace recovery suffers from low precision due to polysemy, which refers to the coexistence of multiple meanings for a term appearing in different requirements. Latent semantic indexing (LSI) has been introduced as a method to tackle polysemy, as well as synonymy. However, little is known about the scope and significance of polysemous terms in requirements tracing. While quantifying the effect, we present a novel method based on artificial neural networks (ANN) to enhance the capability of automatically resolving polysemous terms. The core idea is to build an ANN model which leverages a term's highest-scoring coreferences in different requirements to learn whether this term has the same meaning in those requirements. Experimental results based on 2 benchmark datasets and 6 long-lived open-source software projects show that our approach outperforms LSI on identifying polysemous terms and hence increasing the precision of automated tracing.

Programmer-provided identifier names convey information about the semantics of a program. This information can complement traditional program analyses in various software engineering tasks, such as bug finding, code completion, and documentation. Even though identifier names appear to be a rich source of information, little is known about their properties and their potential usefulness. This paper presents an empirical study of the lexical similarity between arguments and parameters of methods, which is one prominent situation where names can provide otherwise missing information. The study involves 60 real-world Java programs. We find that, for most arguments, the similarity is either very high or very low, and that short and generic names often cause low similarities. Furthermore, we show that inferring a set of low-similarity parameter names from one set of programs allows for pruning such names in another set of programs. Finally, the study shows that many arguments are more similar to the corresponding parameter than any alternative argument available in the call site's scope. As applications of our findings, we present an anomaly detection technique that identifies 144 renaming opportunities and incorrect arguments in 14 programs, and a code recommendation system that suggests correct arguments with a precision of 83%.

Software refactoring is a popular technology to improve the design of existing source code, and thus it is widely used to facilitate software evolution. Moving methods is one of the most popular refactorings. It helps to reduce coupling between classes and to improve cohesion of involved classes. However, it is difficult to manually identify such methods that should be moved. Consequently, a number of approaches and tools have been proposed to identify such methods based on source code metrics, change history, and textual information. In this paper we propose a new way to identify methods that should be moved. Whenever a method is moved, the approach checks other methods within the same class, and suggests to move the one with the greatest similarity and strongest relationship with the moved method. The rational is that similar and closely related methods should be moved together. The approach has been evaluated on open-source applications by comparing the recommended move method refactorings against refactoring histories of the involved applications. Our evaluation results show that the approach is accurate in recommending methods to be moved (average precision 76%) and in recommending destinations for such methods (average precision 83%). Our evaluation results also show that for a substantial percentage (27%) of move method refactorings, the proposed approach succeeds in identifying additional refactoring opportunities.

Most code smell detection tools expose thresholds to engineers for customization because code smell detection is essentially subjective and application specific. Another reason why engineers should customize these thresholds is that they have different working schedules and different requirements on software quality. They have their own unique need on precision and recall in smell detection. This unique need should be fulfilled by adjusting thresholds of smell detection tools. However, it is difficult for software engineers, especially inexperienced ones, to adjust often contradicting and related thresholds manually. One of the possible reasons is that engineers do not know the exact quantitative relation between threshold values and performance, e.g., precision. In this paper, we propose an approach to adapting thresholds automatically and dynamically. Engineers set a target precision manually according to their working schedules and quality requirements. With feedback from engineers, the proposed approach then automatically searches for a threshold setting to maximize recall while having precision close to the target precision. The proposed approach has been evaluated on open-source applications. Evaluation results suggest that the proposed approach is effective.

Software refactoring is to improve readability, maintainability and expansibility of software by adjusting its internal structure, whereas the external behaviors of software are not changed. Although software refactoring should not change the external behaviors of software systems, they might make a regression test case obsolete (with syntax and runtime errors) or fail. People have investigated which refactorings had an influence on regression test case. However, how test cases are influenced by refactorings and what kind of errors might be introduced remain unknown. To this end, in this paper, we proposed an approach to analyze refactorings' impact on regression test cases. On one hand, we analyzed why regression test cases failed. On the other hand, we analyzed the influence of refactorings on software interfaces. Based on the analysis, we built up a mapping between refactorings and test case failure. Such a mapping can be used to guide test case repair automation where test cases are made obsolete by refactorings. The approach was evaluated on five open-source applications. Evaluation results suggest that the precision of the approach is greater than 80%.

To facilitate software refactoring, a number of approaches and tools have been proposed to suggest where refactorings should be conducted. However, identification of such refactoring opportunities is usually difficult because it often involves difficult semantic analysis and it is often influenced by many factors besides source code. For example, whether a software entity should be renamed depends on the meaning of its original name (natural language understanding), the semantics of the entity (source code semantics), experience and preference of developers, and culture of companies. As a result, it is difficult to identify renaming opportunities. To this end, in this paper we propose an approach to identify renaming opportunities by expanding conducted renamings. Once a rename refactoring is conducted manually or with tool support, the proposed approach recommends to rename closely related software entities whose names are similar to that of the renamed entity. The rationale is that if an engineer makes a mistake in naming a software entity it is likely for her to make the same mistake in naming similar and closely related software entities. The main advantage of the proposed approach is that it does not involve difficult semantic analysis of source code or complex natural language understanding. Another advantage of this approach is that it is less influenced by subjective factors, e.g., experience and preference of software engineers. The proposed approach has been evaluated on four open-source applications. Our evaluation results show that the proposed approach is accurate in recommending entities to be renamed (average precision 82 percent) and in recommending new names for such entities (average precision 93 percent). Evaluation results also suggest that a substantial percentage (varying from 20 to 23 percent) of rename refactorings are expansible.

Just-in-time requirements management, characterized by lightweight representation and continuous refinement of requirements, fits many iterative and incremental development projects. Being lightweight and flexible, however, can cause wasteful and procrastinated implementation, leaving certain stakeholder goals not satisfied. This paper proposes traceability-enabled refactoring aimed at fulfilling more requirements fully. We make a novel use of requirements traceability to accurately locate where the software should be refactored, and develop a new scheme to precisely determine what refactorings should be applied to the identified places. Our approach is evaluated through an industrial study. The results show that our approach recommends refactorings more appropriately than a contemporary recommender.

Software refactoring is an effective method for improvement of software quality while software external behavior remains unchanged. To facilitate software refactoring, a number of tools have been proposed for code smell detection and/or for automatic or semi-automatic refactoring. However, these tools are passive and human driven, thus making software refactoring dependent on developers' spontaneity. As a result, software engineers with little experience in software refactoring might miss a number of potential refactorings or may conduct refactorings later than expected. Few refactorings might result in poor software quality, and delayed refactorings may incur higher refactoring cost. To this end, we propose a monitor-based instant refactoring framework to drive inexperienced software engineers to conduct more refactorings promptly. Changes in the source code are instantly analyzed by a monitor running in the background. If these changes have the potential to introduce code smells, i.e., signs of potential problems in the code that might require refactorings, the monitor invokes corresponding smell detection tools and warns developers to resolve detected smells promptly. Feedback from developers, i.e., whether detected smells have been acknowledged and resolved, is consequently used to optimize smell detection algorithms. The proposed framework has been implemented, evaluated, and compared with the traditional human-driven refactoring tools. Evaluation results suggest that the proposed framework could drive inexperienced engineers to resolve more code smells (by an increase of 140 percent) promptly. The average lifespan of resolved smells was reduced by 92 percent. Results also suggest that the proposed framework could help developers to avoid similar code smells through timely warnings at the early stages of software development, thus reducing the total number of code smells by 51 percent.

Software refactoring might be done in two different tactics. The first one is XP-style small-step refactoring, also called floss refactoring. The other tactic, called root canal refactoring, is to set aside an extended period specially for refactoring. Floss refactoring, as one of the corner stones of XP, is well acknowledged. In contrast, root canal refactoring is doubted, especially by XP advocators. Despite the doubts, however, no large scale empirical study on refactoring tactics has been reported. In contrast to the doubts, cases of root canal refactoring have been reported from industry, e.g., Microsoft. Researchers from academe have also proposed various approaches to facilitating root canal refactoring. To this end, this paper would investigate the following questions. (1)How often are the two different tactics employed, respectively? (2) Is there any correlation between refactoring tactics and categories of refactorings? In other words, are some kinds of refactorings more likely than others to be done as floss refactorings or root canal refactorings? To answer these questions, we analyze refactoring histories collected by Eclipse Usage Data Collector (UDC). The data are collected from 753,367 engineers worldwide. Analysis results suggest that about 11.5 percent of refactorings collected by UDC are root canal refactorings, whereas others (88.5 percent) are floss refactorings. We also find that some kinds of refactorings, e.g., Introduce Parameter, are more likely than others to be performed as root canal refactorings.

Bad smells are signs of potential problems in code. Detecting and resolving bad smells, however, remain time-consuming for software engineers despite proposals on bad smell detection and refactoring tools. Numerous bad smells have been recognized, yet the sequences in which the detection and resolution of different kinds of bad smells are performed are rarely discussed because software engineers do not know how to optimize sequences or determine the benefits of an optimal sequence. To this end, we propose a detection and resolution sequence for different kinds of bad smells to simplify their detection and resolution. We highlight the necessity of managing bad smell resolution sequences with a motivating example, and recommend a suitable sequence for commonly occurring bad smells. We evaluate this recommendation on two nontrivial open source applications, and the evaluation results suggest that a significant reduction in effort ranging from 17.64 to 20 percent can be achieved when bad smells are detected and resolved using the proposed sequence.

Long and complex methods are hard to read or maintain, and thus usually treated as bad smells, known as Long Method. On the contrary, short and well-named methods are much easier to read, maintain, and extend. In order to divide long methods into short ones, refactoring Extract Method was proposed and has been widely used. However, extracting methods manually is time consuming and error prone. Though existing refactoring tools can automatically extract a selected fragment from its inclosing method, which fragment within a long method should be extracted has to be determined manually. In order to facilitate the decision-making, we propose an approach to recommend fragments within long methods for extraction. The approach is implemented as a prototype, called AutoMeD. With the tool, we evaluate the approach on a nontrivial open source project. The evaluation results suggest that refactoring cost of long methods can be reduced by nearly 40%. The main contribution of this paper is an approach to recommending fragments within long methods to be extracted, as well as an initial evaluation of the approach.

Bad smell is a key concept in software refactoring. We have a bunch of bad smells, refactoring rules, and refactoring tools, but we do not know which kind of bad smells should be resolved first. The resolution of one kind of bad smells may have impact on the resolution of other bad smells. Con-sequently, different resolution orders of the same set of bad smells may require different effort, and/or lead to differ-ent quality improvement. In order to ease the work and maximize the effect of refactoring, we try to analyze the re-lationships among different kinds of bad smells, and their impact on resolution orders of these bad smells. With the analysis, we recommend a resolution order of common bad smells. The main contribution of this paper is to motivate the necessity to arrange resolution orders of bad smells, and recommend a resolution order of common bad smells.

Software refactoring is to restructure object-oriented software to improve its quality, especially extensibility, reusability and maintainability while preserving its external behaviors. For a special software system, there are usually quite a few refactorings available at the same time. But these refactorings may conflict with each other. In other words, carrying out a refactoring may disable other refactorings. Consequently, only a subset of the available refactorings can be applied together, and which refactorings will be applied depends on the schedule (application order) of the refactorings. Furthermore, carrying out different subsets of the refactorings usually leads to different improvement of software quality. As a result, in order to promote the improvement of software quality, refactorings should be scheduled rationally. However, how to schedule refactorings is rarely discussed. Usually, software engineers carry out refactorings immediately when they are found out. They do not wait until all applicable refactorings are found out and scheduled. In other words, the refactorings are not scheduled explicitly, and conflicts among them are not taken into consideration. Though more and more refactorings are formalized and automated by refactoring tools, refactoring tools apply refactorings usually in a nondeterministic fashion (in random). In this paper, we propose a scheduling approach to schedule conflicting refactorings to promote the improvement of software quality achieved by refactorings. Conflicts among refactorings are detected, and then a scheduling model is presented. And then a heuristic algorithm is proposed to solve the scheduling model. Results of experiments suggest that the proposed scheduling approach is effective in promoting the improvement of software quality

With the popularity of UML and MDA, models are replacing source code as core artifacts of software development and maintenance. But duplications in models reduce models' maintainability and reusability. To address the problem, we should detect duplications first. As an initial step to address the problem, we propose an approach to detect duplications in sequence diagrams. With special preprocessing, we convert 2-dimensional sequence diagrams into a 1-dimensional array. Then we construct a suffix tree of the array. We revise the traditional construction algorithm of suffix trees by proposing a special algorithm to detect common prefixes of suffixes. The algorithm ensures that every duplication detected with the suffix tree can be extracted into a separate reusable sequence diagram. With the suffix tree, duplications are found as refactoring candidates. With tool support, the proposed approach has been applied to real industrial projects, and the evaluation results suggest that the approach is effective.