ABSTRACT
Highly-configurable software systems (also called software product lines) gain momentum in both, academia and industry. For instance, the Linux kernel comes with over 12 000 configuration options and thus, can be customized to run on nearly every kind of system. To a large degree, this configurability is achieved through variable code structures, for instance, using conditional compilation. Such source code variability adds a new dimension of complexity, thus giving rise to new possibilities for design flaws. Code smells are an established concept to describe design flaws or decay in source code. However, existing smells have no notion of variability and thus do not support flaws regarding variable code structures. In this paper, we propose an initial catalog of four variability-aware code smells. We discuss the appearance and negative effects of these smells and present code examples from real-world systems. To evaluate our catalog, we have conducted a survey amongst 15 researchers from the field of software product lines. The results confirm that our proposed smells (a) have been observed in existing product lines and (b) are considered to be problematic for common software development activities, such as program comprehension, maintenance, and evolution.
- M. Abbes, F. Khomh, Y.-G. Guéhéneuc, and G. Antoniol, "An empirical study of the impact of two antipatterns, blob and spaghetti code, on program comprehension," in CSMR. IEEE, 2011, pp. 181--190. Google ScholarDigital Library
- S. Apel, D. Batory, C. Kästner, and G. Saake, Feature-Oriented Software Product Lines. Springer, 2013. Google ScholarCross Ref
- S. Apel, C. Kästner, and C. Lengauer, "Language-independent and automated software composition: The FeatureHouse experience," IEEE Trans. Softw. Eng., vol. 39, no. 1, pp. 63--79, 2013. Google ScholarDigital Library
- D. Batory, "Feature models, grammars, and propositional formulas," in SPLC. Springer, 2005, pp. 7--20. Google ScholarDigital Library
- D. Batory, J. N. Sarvela, and A. Rauschmayer, "Scaling step-wise refinement," IEEE Trans. Softw. Eng., vol. 30, no. 6, pp. 355--371, 2004. Google ScholarDigital Library
- I. D. Baxter and M. Mehlich, "Preprocessor conditional removal by simple partial evaluation," in WCRE. IEEE, 2001, pp. 281--290. Google ScholarDigital Library
- W. H. Brown, R. C. Malveau, and T. J. Mowbray, AntiPatterns: refactoring software, architectures, and projects in crisis. Wiley & Sons, 1998. Google ScholarDigital Library
- K. Czarnecki and U. W. Eisenecker, Generative Programming. Addison Wesley, 2000.Google ScholarDigital Library
- H. S. de Andrade, E. Almeida, and I. Crnkovic, "Architectural bad smells in software product lines: An exploratory study," in WICSA Companion Volume. ACM, 2014, pp. 12:1--12:6. Google ScholarDigital Library
- M. D. Ernst, G. J. Badros, and D. Notkin, "An empirical analysis of C preprocessor use," IEEE Trans. Softw. Eng., vol. 28, no. 12, pp. 1146--1170, 2002. Google ScholarDigital Library
- J. Feigenspan, C. Kastner, J. Liebig, S. Apel, and S. Hanenberg, "Measuring programming experience," in ICPC. IEEE, 2012, pp. 73--82.Google Scholar
- M. Fowler, K. Beck, J. Brant, and W. Opdyke, Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999. Google ScholarDigital Library
- M. L. Griss, "Implementing product-line features by composing aspects," in SPLC. Kluwer Academic Publishers, 2000, pp. 271--288. Google ScholarDigital Library
- E. Guimaraes, A. Garcia, E. Figueiredo, and Y. Cai, "Prioritizing software anomalies with software metrics and architecture blueprints," in MiSE. IEEE, 2013, pp. 82--88. Google ScholarDigital Library
- E. Jürgens, F. Deissenboeck, B. Hummel, and S. Wagner, "Do code clones matter?" in ICSE. IEEE, 2009, pp. 485--495. Google ScholarDigital Library
- K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson, "Feature-oriented domain analysis (FODA) feasibility study," SEI, USA, Tech. Rep. CMU/SEI-90-TR-21, 1990.Google Scholar
- C. Kapser and M. W. Godfrey, ""Cloning considered harmful" considered harmful: Patterns of cloning in software," Empir. Softw. Eng., vol. 13, no. 6, pp. 645--692, 2008. Google ScholarDigital Library
- C. Kästner and S. Apel, "Virtual separation of concerns -- a second chance for preprocessors," J. Object Technology, vol. 8, no. 6, pp. 59--78, 2009.Google ScholarCross Ref
- C. Kästner, S. Apel, and M. Kuhlemann, "Granularity in software product lines," in ICSE. ACM, 2008, pp. 311--320. Google ScholarDigital Library
- J. Kerievsky, Refactoring to Patterns. Pearson Higher Education, 2004. Google ScholarDigital Library
- F. Khomh, M. Di Penta, and Y. Gueheneuc, "An exploratory study of the impact of code smells on software change-proneness," in WCRE. IEEE, 2009, pp. 75--84. Google ScholarDigital Library
- M. Lanza, R. Marinescu, and S. Ducasse, Object-Oriented Metrics in Practice. Springer, 2006. Google ScholarDigital Library
- Z. Li, S. Lu, S. Myagmar, and Y. Zhou, "CP-Miner: Finding copy-paste and related bugs in large-scale software code," IEEE Trans. Softw. Eng., vol. 32, no. 3, pp. 176--192, 2006. Google ScholarDigital Library
- J. Liebig, S. Apel, C. Lengauer, C. Kästner, and M. Schulze, "An analysis of the variability in forty preprocessor-based software product lines," in ICSE. ACM, 2010, pp. 105--114. Google ScholarDigital Library
- R. E. Lopez-Herrejon and D. Batory, "A standard problem for evaluating product-line methodologies," in GCSE. Springer, 2001, pp. 10--24. Google ScholarDigital Library
- I. Macia, J. Garcia, D. Popescu, A. Garcia, N. Medvidovic, and A. von Staa, "Are automatically-detected code anomalies relevant to architectural modularity?: an exploratory analysis of evolving systems," in AOSD. ACM, 2012, pp. 167--178. Google ScholarDigital Library
- I. Macia Bertran, A. Garcia, and A. von Staa, "An exploratory study of code smells in evolving aspect-oriented systems," in AOSD, 2011, pp. 203--214. Google ScholarDigital Library
- R. C. Martin and M. Martin, Agile Principles, Patterns, and Practices in C#. Prentice Hall, 2006. Google ScholarDigital Library
- N. Moha, "Detection and correction of design defects in object-oriented designs," in OOPSLA. ACM, 2007, pp. 949--950. Google ScholarDigital Library
- N. Moha, Y.-G. Guéhéneuc, A.-F. Le Meur, and L. Duchien, "A domain analysis to specify design defects and generate detection algorithms," in FASE. Springer, 2008, pp. 276--291. Google ScholarDigital Library
- M. P. Monteiro and J. a. M. Fernandes, "Towards a catalogue of refactorings and code smells for AspectJ," Trans. Aspect-Oriented Softw. Dev. I, vol. 3880, pp. 214--258, 2006. Google ScholarDigital Library
- T. Patzke, M. Becker, M. Steffens, K. Sierszecki, J. E. Savolainen, and T. Fogdal, "Identifying improvement potential in evolving product line infrastructures: 3 case studies," in SPLC. ACM, 2012, pp. 239--248. Google ScholarDigital Library
- C. Prehofer, "Feature-oriented programming: A fresh look at objects," in ECOOP. Springer, 1997, pp. 419--443.Google Scholar
- M. Rosenmüller, M. Kuhlemann, N. Siegmund, and H. Schirmeier, "Avoiding variability of method signatures in software product lines: A case study," in GPCE Workshop on Aspect-Oriented Product Line Engineering, 2007, pp. 20--25.Google Scholar
- C. K. Roy and J. R. Cordy, "A survey on software clone detection research," Queen's University at Kingston, Canada, Tech. Rep. 541, 2007.Google Scholar
- S. Schulze, S. Apel, and C. Kästner, "Code clones in feature-oriented software product lines," in GPCE. ACM, 2010, pp. 103--112. Google ScholarDigital Library
- S. Schulze, E. Jürgens, and J. Feigenspan, "Analyzing the effect of preprocessor annotations on code clones," in SCAM. IEEE, 2011, pp. 115--124. Google ScholarDigital Library
- S. Schulze, J. Liebig, J. Siegmund, and S. Apel, "Does the discipline of preprocessor annotations matter? A controlled experiment," in GPCE. ACM, 2013, pp. 65--74. Google ScholarDigital Library
- S. Schulze, O. Richers, and I. Schaefer, "Refactoring delta-oriented software product lines," in AOSD. ACM, 2013, pp. 73--84. Google ScholarDigital Library
- D. C. Sharp, "Reducing avionics software cost through component based product line development," in DASC, vol. 2. IEEE, 1998, pp. G32/1--G32/8.Google Scholar
- H. Spencer and G. Collyer, "#ifdef considered harmful, or portability experience with C News," in USENIX Tech. Conf. USENIX association, 1992.Google Scholar
- T. Thüm, C. Kästner, F. Benduhn, J. Meinicke, G. Saake, and T. Leich, "FeatureIDE: An extensible framework for feature-oriented software development," Sci. Comp. Prog., vol. 79, pp. 70--85, 2014. Google ScholarDigital Library
- E. Van Emden and L. Moonen, "Java quality assurance by detecting code smells," in WCRE. IEEE, 2002, pp. 97--106. Google ScholarDigital Library
- A. Yamashita, "How good are code smells for evaluating software maintainability? results from a comparative case study," in ICSM. IEEE, 2013, pp. 566--571. Google ScholarDigital Library
Index Terms
- Code Smells Revisited: A Variability Perspective
Recommendations
Are architectural smells independent from code smells? An empirical study
Highlights- Case study analyzing the correlations among code smells, groups of code smells and architectural smells.
AbstractBackground. Architectural smells and code smells are symptoms of bad code or design that can cause different quality problems, such as faults, technical debt, or difficulties with maintenance and evolution. Some studies ...
Detecting Code Smells in Software Product Lines -- An Exploratory Study
ITNG '15: Proceedings of the 2015 12th International Conference on Information Technology - New GenerationsCode smells are symptoms that something is wrong in the source code. They have been catalogued and investigated in several programming techniques. These techniques can be used to develop Software Product Lines (SPL). However, feature-oriented ...
An interactive ambient visualization for code smells
SOFTVIS '10: Proceedings of the 5th international symposium on Software visualizationCode smells are characteristics of software that indicate that code may have a design problem. Code smells have been proposed as a way for programmers to recognize the need for restructuring their software. Because code smells can go unnoticed while ...
Comments