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.

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.