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.

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.

Online code clones occur due to reusing code snippets in software repositories from online resources such as GitHub and Stack Overflow. Previous works have shown that snippets from Stack Overflow are reused in other open-source projects and vice versa. Analysis of online code reusing patterns could identify outdated code, understand developers' practices, and help to design new code search engines. This study analyzed JavaScript online code clones between Stack Overflow and GitHub repositories. We first developed a JavaScript code corpus to search online clones. The clone search results reported 12,579 online clones between 276,547 non-trivial syntactically validated Stack Overflow snippets and 292 GitHub repositories. We manually classified the top 10% (1257) pairs of clones in seven online clone patterns. We observed that around 70% of JavaScript snippets in Stack Overflow posts are copied from GitHub repositories or from other external sources. Moreover, only 30.59% of JavaScript Snippets in Stack Overflow accepted answers could be considered as reusable snippets.

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.

Move Method Refactoring (MMR) is used to place highly coupled methods in appropriate classes for making source code more cohesive. Like other refactoring techniques, it is mandatory that applying MMR will preserve applications’ behaviors. However, traditional MMR techniques failed to meet this essential precondition for Action methods in web-based application and API methods in libraries projects. The reason is that applying MMR on these methods changes the behaviors of the projects by raising Application-breaking issues, for instance, failure of browser requests and compilation errors in client projects. To resolve this problem, developers are suggested to manually check Action and API methods while applying MMR. However, manually inspecting thousands of lines of code for these issues is a time-consuming and hectic task. In this paper, an advanced MMR technique is proposed which automatically identifies Application-breaking MMR suggestions. This technique first takes the initial move method suggestions from the existing prominent MMR techniques e.g. JDeodorant. For each of the suggestions, it parses the source code and construct Abstract Syntax Tree to examine two types of usage. One is whether a suggestion has not been used in any unit test and Regular Class, and another is whether the suggestion has been used in unit test classes only. If any MMR suggestion is found having one of these two types of usage or both, the respective suggestion is marked as Application-breaking. In order to evaluate the proposed technique, several experiments have been conducted on open source projects. The experimental results show that the proposed technique achieved 96.4% Precision, 90% Recall and 93.1% F-score in detecting Application-breaking MMR suggestions, because of considering external dependencies of the MMR suggestions.

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.

Developers need to put lots of time and effort to reuse the code snippets retrieved by the existing code search engines. The reason is that these engines do not provide self-executable, functionally correct and easily understandable code snippets as search results. Developers manually resolve all the dependencies to make the code snippets executable in their development contexts. They have to write and execute the same test cases many times to check the correctness of the code fragments. In this paper, a technique has been proposed that converts each method in a code base into self-executable method (i.e., program slice) by resolving method calls, data and library dependencies. To ensure that the methods are functionally correct, automatic test scripts are generated and executed for each self-executable method based on the branch, statement, and path coverage. The understandability of the code fragments is increased by replacing irrelevant textual keywords with relevant words. All the self-executable code fragments are indexed using traditional Information Retrieval approach. So, when a user query is submitted, the technique will retrieve self-executable and functionally correct code snippets.