ABSTRACT Context Code smells are indicators of poor design and implementation choices that negatively affect software quality and maintainability. Moreover, it is difficult and time‐consuming to work with a long list of the code smells, as not all of those smells have equal impact on the system. So, understanding the individual impact of the code smells is significant while performing refactorings on a priority basis. Objective Despite significant research efforts aimed at detecting and refactoring these code smells, understanding their individual impact on software quality metrics such as size, complexity, coupling, etc. remains still unclear. Methodology To mitigate this research gap, we present an empirical investigation on the impact analysis of code smells based on the 25 software quality metrics such as size, cyclomatic complexity, coupling, etc. To the best of our knowledge, this is the largest empirical study about the impact analysis of code smells with respect to the number of software metrics. Particularly for this study, we identify 13 code smells in 35 open‐source software systems, and analyze (1) the relationship between code smells and software metrics, (2) which code smells are highly impactful that affect the metrics, and (3) which impactful smells occur frequently in the systems. Results The results show varying degrees of correlation‐based impact between specific code smells and software metrics, with some smells showing strong correlations with multiple metrics. Three categories of impact for the code smells have been identified, namely High, Moderate and Low, where Long Method, Anti Singleton, Complex Class, Large Class and Long Parameter List smells have high impact, but their frequencies are not high except Anti Singleton; Refused Parent Bequest, Spaghetti Code and Blob have moderate impact; and rest of the smells have low impact. We also observe that perceptions about the impact of code smells vary from developer to developer and they most cases refactor the smells based on their intuition. Conclusion Our findings will help them to refactor the smells on an objective‐based instead of an intuition‐based, which will be more significant to improve the software quality. For example, refactoring the smells having a high impact on the coupling between objects metric can be an objective. Furthermore, our results will not only assist developers in prioritizing refactoring activities but also provide researchers with valuable insights to innovate tools that prioritize refactoring based on the impact of code smells. These tools will help developers target the most impactful smells and thus enhance the overall quality and maintainability of software systems.

Fault-proneness is an indication of programming errors that decreases software quality and maintainability. On the contrary, code smell is a symptom of potential design problems which has impact on fault-proneness. In the literature, negative impact of code smells on fault-proneness has been investigated. However, it is still unclear that how frequency of each code smell type impacts the fault-proneness. To mitigate this research gap, we present an empirical study to identify whether frequency of individual code smell types has a relationship with the fault-proneness. The results show that Anti Singleton, Blob and Class Data Should Be Private smell types have strong relationship with fault-proneness though their frequencies are not very high. On the other hand, comparatively high frequent code smell types such as Complex Class, Large Class and Long Parameter List have moderate relationship with fault-proneness. These findings will assist developers to prioritize and refactor code smells to improve software quality.

Background: Reusing source code containing code smells can induce significant amount of maintenance time and cost. A list of code smells has been identified in the literature and developers are encouraged to avoid the smells from the very beginning while writing new code or reusing existing code, and it increases time and cost to identify and refactor the code after the development of a system. Again, remembering a long list of smells is difficult specially for the new developers. Besides, two different types of software development environment - open source and industry, might have an effect on the occurrences of code smells. Aims: A study on the occurrences of code smells in open source and industrial systems can provide insights about the most frequently occurring smells in each type of software system. The insights can make developers aware of the most frequent occurring smells, and researchers to focus on the improvement and innovation of automatic refactoring tools or techniques for the smells on priority basis. Method: We have conducted a study on 40 large scale Java systems, where 25 are open source and 15 are industrial systems, for 18 code smells. Results: The results show that 6 smells have not occurred in any system, and 12 smells have occurred 21,182 times in total where 60.66% in the open source systems and 39.34% in the industrial systems. Long Method, Complex Class and Long Parameter List have been seen as frequently occurring code smells. The one tailed t-test with 5% level of significant analysis has shown that there is no difference between the occurrences of 10 code smells in industrial and open source systems, and 2 smells are occurred more frequently in open source systems than industrial systems. Conclusions: Our findings conclude that all smells do not occur at the same frequency and some smells are very frequent. The short list of most frequently occurred smells can help developers to write or reuse source code carefully without inducing the smells from the beginning during software development. Our study also concludes that industry and open source environments do not have significant impact on the occurrences of code smells.

Misplacement of classes makes poor design quality of an application in terms of software modularization. It causes inefficient software design and increases maintenance cost, time and effort. So, placement of classes is one of the most important design activities to optimize modularization in any object oriented application. Move class, a refactoring technique assists to achieve this design aspect by placing a target class in a more appropriate package (or folder). Although it is an important design aspect, there exist few works regarding this refactoring technique. However, existing works have not considered contextual information of an application, though context of classes in a package provides significant information to group related classes. Therefore, this paper proposes an idea of recommending move class refactoring for a target class based on the contextual similarity between the class's current package and the other packages of the application. An Information Retrieval (IR) technique, cosine similarity is used to measure context based similarity which provides a new dimension in the refactoring research field.

Summary Placement of methods is one of the most important design activities for any object‐oriented application in terms of coupling and cohesion. Due to method misplacement, the application becomes tightly coupled and loosely cohesive, reflecting inefficient design. Therefore, a feature envy code smell emerges from the application, as many methods use more features of other classes than its current class. Hence, development and maintenance time, cost, and effort are increased. To refactor the code smell and enhance the design quality,move methodrefactoring plays a significant role through grouping similar behaviors of methods. This is because the manual refactoring process is infeasible due to the necessity of huge time and most of the existing techniques consider only coupling‐based and/or cohesion‐based information of nonstatic entities (methods and attributes) for the recommendation. However, this article proposes an approach that uses contextual information, based on information retrieval techniques, along with dependency (coupling and cohesion)‐based information of the application for the recommendation. In addition, the approach incorporates both static and nonstatic entities in the recommendation process. For validation, the approach is applied on seven well‐known open source projects. The results of the experimental evaluation indicate that the proposed approach provides better results with an average precision of 18.91%, a recall of 69.91%, and an F‐measure of 29.77% than the JDeodorant tool (a widely used eclipse plugin for refactorings). Moreover, this article establishes several relationships between the accuracy of the approach and project standards and sizes.