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.

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.

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.