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.

Reducing production cost is vital for ensuring sustainable competitive strength. This is particularly true in software development, in which there has been a move from in-house development to global and now also to offshore-outsourced software development. In offshore outsourcing, development activities are most often moved to low-cost development environments that are locally managed. However, this type of outsourcing is not without problems. Most development projects are complex, and moving control and responsibility away from the client increase complexity. But, there is a trade-off between cost and complexity and control, as well as an increased chance of failure of the project. This paper contributes to identify the goals from the early development components and risk factors threatening the goals to fulfill. A goal-driven software development risk management modeling (GSRM) propose to supports this task. We conducted a study based on Delphi survey process to obtain the goals and the risk factors in a different cultural environment for the offshore vendors in Bangladesh.