Recently, Coding Agents gained considerable impact on software engineering processes such as on reviews, tests, documentation, code generation, but also pull requests. Those Agentic Pull Requests flood repositories, and thus, cause considerable effort for integrators that must review these pull requests. However, so far it is unclear which factors influence the acceptance of Agentic Pull Requests. Providing insights would help to improve Coding Agents, support integrators, and provide guidelines for users creating Agentic Pull Requests.

Outside of performance-focused domains, research software is typically designed with output in mind rather than runtime efficiency. So, the resulting software consumes more resources (time, hardware) and is less scalable, hindering larger or longitudinal studies without adaptations. In this paper, we report our experiences of iteratively identifying and optimizing performance bottlenecks to enable such analyses in an established research software. Specifically, we applied a top-down strategy to Arcan, an architecture-smell detection tool, to develop a tool (AsTdEA) for tracing architecture smells through software evolution. To identify performance bottlenecks and benchmark our improvements, we used the Qualitas Corpus and a custom dataset. We achieved a reduction in processing time of approx. 98 % and reduced the runtime complexity from almost quadratic to close-to-linear. By sharing our process and insights, we hope to guide researchers in optimizing their research software in the future.

Forking is a common practice in open-source and industrial software development, leading to the emergence of complex fork ecosystems. Understanding the evolution and relationships within such ecosystems is crucial for developers and project managers to ensure that useful changes are merged back into the original project or synchronized between forks. However, understanding complex fork ecosystems with up to tens of thousands of forks in different states (e.g., abandoned, co-evolving) is challenging, with visualizations being a means to address this challenge. In this paper, we investigate six visualizations designed to provide key insights into the dynamics of fork ecosystems. We started our work by analyzing GitHub community feedback on the official Network Graph visualization for fork ecosystems and categorized the fork-related tasks mentioned by developers in 237 comments. Then, we designed our visualization prototype VisFork, which contains six different visualizations that serve the three most frequently mentioned tasks. These visualizations allow users to explore temporal patterns, commit classifications, and collaboration dynamics across a fork ecosystem. Through a user study involving 10 GitHub community participants and seven students, we evaluated the usefulness of the visualizations. The results demonstrate the potential of VisFork to provide valuable insights into fork ecosystems, with positive feedback on the visualizations, but also suggestions for further improvements. Our work contributes to the development of user-centered tools that help to understand the intricacies of fork-based development and promote collaborative software-development practices.

Architecture smells are a widely established concept to describe symptoms of software degradation by measuring perceived violations of software-design principles. As such, architecture smells can help developers assess and understand the architectural quality of their software system. However, research has rarely been concerned with how architecture smells evolve and whether they actually foster software degradation during a system’s evolution. Building on our previous work in this direction, we present extended techniques for measuring architecture smells, novel visualizations, as well as an empirical study of how architecture smells evolve and what typical patterns they exhibit in 485 releases of 14 open-source systems. Among others, the results of our study indicate that especially cyclic dependencies on the class-level are prone to becoming highly complex over time, with one of the reasons being the continued merging of smells, most often resulting in tangled multi-hubs. Moreover, we found unstable dependencies to mostly grow slowly over time, whereas hub-like dependencies remain rather stable during a system’s evolution. These findings are valuable for practitioners to identify and tackle system degeneration, as well as for researchers to scope new research on managing architecture smells and technical debt.

Architecture smells indicate violations of software-design principles. So, identifying and assessing architecture smells facilitates refactorings to reduce technical debt and ensure maintainability. Detecting architecture smells in only one version at a time provides a static and limited picture, since, for example, historical trends remain obfuscated. Both, for practitioners and researchers, obtaining information on how specific architecture smells evolved over time can yield valuable insights, be it for avoiding the growth of critical smells, grasping the code’s degradation, or getting a better understanding of development processes. To support such analyses, we developed our tool AsTdEA, which tracks architecture smells throughout a system’s evolution. AsTdEA runs a modified version of the architecture-smell detection tool Arcan and allows the automated batch-processing of multiple versions of one or multiple systems. First, AsTdEA generates data on the components that are involved in each smell on a version-to-version basis and how these intra-version smells are related with one another across the entire system history, forming inter-version smells. Second, for every intra-version smell, inter-version smell, and system version, AsTdEA outputs a multitude of properties, which we have already used for multiple empirical studies. In this paper, we show the implementation and use of AsTdEA, as well as the lessons that we learned during its development and how we want to improve it in the future.

Configurable software systems and software product lines build on features as first class entities for reasoning about commonalities and variability among system variants. While it is desirable to have modular features, this is not always achievable and research has shown that features interact frequently, which can come with negative effects like security vulnerabilities or bugs. Intensive research has been conducted regarding how and when features interact, focusing primarily on the implementation level and the variability mechanism therein. However, besides such structural, explicit feature dependencies represented in the code, there may also be more subtle, implicit feature dependencies. In this paper, we build on the idea that the co-evolution of features (i.e., co-changes between features) can reveal implicit dependencies, and thus point to poor design decisions that result in additional maintenance effort. We present a technique for analyzing feature co-changes based on repository mining and association rule mining to identify features that commonly change together and to reveal implicit dependencies. Moreover, we provide a large-scale multi-case study on five C systems (e.g., Linux kernel) to evaluate whether and how frequent such evolutionary dependencies occur. Our results reveal that a) feature co-changes occur quite frequently (25 to 70% of commits), b) a considerable amount of changes are supported by association rules (i.e, do not occur by chance), and c) several of these co-changes cannot be explained via explicit feature interactions. Overall, our technique and study complement existing research on feature dependencies and interactions by providing means for understanding implicit dependencies that are represented by feature co-evolution.

If software quality assurance is postponed or even abandoned for a software system, maintenance and evolution become harder or even impossible. One widely known symptom for the degradation of system quality are Architecture Smells (ASs), which violate fundamental principles of software design. In this paper, we present a study on the evolution of ASs as well as on how and when they foster system degradation. Thus, we provide valuable insights regarding what ASs are meaningful to assure system quality. To this end, we analyzed the evolution of three types of ASs in 14 open-source systems with a total of 485 versions. We adapted indicators used in previous studies to assess the severity of ASs (e.g., growth, lifetime), and relate ASs to technical debt as another established indicator. Our results indicate that 1) ASs remain mostly stable compared to the code size of a system, 2) certain types of ASs, such as cyclic dependencies, have a greater impact on system degradation, and 3) certain properties determine how much an AS contributes to software degradation. These findings are valuable for practitioners to identify and tackle system degeneration, as well as for researchers to scope new research on managing ASs and technical debt.

In Software Product Lines (SPL), feature extraction from software requirements specifications has been subject to intense research in order to assist domain analysis in a time-saving way. Although various approaches are proposed to extract features, there still exists a gap to achieve the complete view of features, that is, how to figure out the intention of a feature. Feature terms as the smallest units in a feature can be regarded as vital indicators for describing a feature. Automated feature term extraction can provide key information regarding the intention of a feature, which improves the efficiency of domain analysis. In this paper, we propose an approach to train prediction models by using machine learning techniques to identify feature terms. To this end, we extract candidate terms from requirement specifications in one domain and take six attributes of each term into account to create a labeled dataset. Subsequently, we apply seven commonly used machine algorithms to train prediction models on the labeled dataset. We then use these prediction models to predict feature terms from the requirements belonging to the other two different domains. Our results show that (1) feature terms can be predicted with high accuracy of ≈ 90% within a domain (2) prediction across domains leads to a decreased but still good accuracy (≈ 80%), and (3) machine learning algorithms perform differently.

Many organizations and open-source projects use the C preprocessor (CPP) to implement configurability in their software systems. Despite extensive research, existing studies on the effects of CPP use on program comprehension are still limited to experiences, opinions, and empirical studies with narrow scopes. So, it is unclear whether the CPP actually leads to what is sometimes referred to as "#ifdef hell." In this paper, we expand the existing evidence on program comprehension in the presence of CPP directives, but we also highlight a surprising dilemma. We conducted an empirical study, including an experiment and a questionnaire, on the impact of refactoring CPP directives with 521 experienced software developers. The results indicate that, in contrast to previous findings, comprehension performance slightly worsened in terms of correctness when our participants worked on code with refactored CPP directives. However, in alignment with previous findings, they preferred the refactored code, considering it more comprehensible and easier to work with. This dilemma of objective performance versus subjective preference is a surprising outcome that has not been found before. We argue that our work motivates the need for more studies to understand this dilemma-which may significantly impact common beliefs in research and practice.

Highly-configurable systems encompass thousands of interdependent configuration options, which require a non-trivial configuration process. Decision propagation enables a backtracking-free configuration process by computing values implied by user decisions. However, employing decision propagation for large-scale systems is a time-consuming task and, thus, can be a bottleneck in interactive configuration processes and analyses alike. We propose modal implication graphs to improve the performance of decision propagation by precomputing intermediate values used in the process. Our evaluation results show a significant improvement over state-of-the-art algorithms for 120 real-world systems.

Model-based languages such as MATLAB/Simulink are crucial for the development of embedded software systems. To adapt to changing requirements, engineers commonly copy and modify existing systems to create new variants. Commonly referred to as clone-and-own, this reuse strategy is easy to apply and beneficial in the short term, but it entails severe maintenance and consistency issues in the long term, leading to a huge amount of redundant and similar assets. Moreover, a later transition towards structured reuse such as with software product lines inevitably requires the comparison of all existing variants prior to the actual migration. However, current work mostly revolves around the comparison of only two systems and despite approaches proposed that can cope with more, such are not applicable to embedded software systems such as MATLAB/Simulink. In this paper, we bridge this gap and propose Static Connectivity Matrix Analysis (SCMA), a novel comparison procedure that allows for the evaluation of multiple MATLAB/Simulink model variants at once. In particular, we transform models into a matrix form which is used to compare all models and to identify all similar structures between them, even with model parts being completely relocated during clone-and-own. We allow engineers to tailor results and to focus on any arbitrary variant subset, enabling individual reasoning prior to migration. We provide a feasibility study from the automotive domain, showing our matrix representation to be suitable and our technique to be fast and precise.

Highly configurable software systems allow the efficient and reliable development of similar software variants based on a common code base. The C preprocessor CPP, which uses source code annotations that enable conditional compilation, is a simple yet powerful text-based tool for implementing such systems. However, since annotations interfere with the actual source code, the CPP has often been accused of being a source of errors and increased maintenance effort. In our research, we have been curious about whether high-level patterns of CPP misuse (i.e., code smells) can be identified, how they evolve, and whether they really hinder maintenance. To support this research, we started a simple tool which over the years evolved into a powerful toolchain. This evolution was possible because our toolchain is not monolithic, but is composed of many small tools connected by scripts and communicating via files. Moreover, we reused existing tools whenever possible and developed our own solutions only as a last resort. In this paper, we report our experiences of building this toolchain. In particular, we present design decisions we made and lessons learned, both positive and negative ones. We hope that this not only stimulates discussion and (in the best case) attracts more researchers in using our tools. Rather, we also want to encourage others to put emphasis on building tools instead of considering them "yet another research prototype".

In practice, organizations often rely on the clone-and-own approach to reuse and customize existing systems. While increasing maintenance costs encourage some organizations to adopt their development processes towards more systematic reuse, others still avoid migrating to a reusable platform. Based on our experiences, a barrier preventing the adoption of software product lines is the fear of introducing new and more problematic bugs---during the migration or later on. We are aware of several works that automate software-product-line adoption, but they neglect the migration and maintenance of test cases. Automating the refactoring of tests can help to facilitate the adoption barrier, compare the quality after migrations, and support maintenance. In this vision paper, we i) discuss open research challenges that are based on our experiences and ii) sketch a first framework to develop automated solutions. Overall, we aim to illustrate our idea and initiate further research to facilitate the adoption and maintenance of software product lines.

Feature and variability extraction from different artifacts is an indispensable activity to support systematic integration of single software systems and Software Product Line (SPL). Beyond manually extracting variability, a variety of approaches, such as feature location in source code and feature extraction in requirements, has been proposed to provide an automatic identification of features and their variation points. Compared with source code, requirements contain more complete variability information and provide traceability links to other artifacts from early development phases. In this paper, we propose a method to automatically extract features and relationships based on a probabilistic relevance and word embedding. In particular, our technique consists of three steps: First, we apply word2vec to obtain a prediction model, which we use to determine the word level similarity of requirements. Second, based on word level similarity and the significance of a word in a domain, we compute the requirements level similarity using probabilistic relevance. Third, we adopt hierarchical clustering to group features and we define four criteria to detect variation points between identified features. We perform a case study to evaluate the usability and robustness of our method and to compare it with the results of other related approaches. Initial results reveal that our approach identifies the majority of features correctly and also extracts variability information with reasonable accuracy.

Dynamic software product lines demand self-adaptation of their behavior to deal with runtime contextual changes in their environment and offer a personalized product to the user. However, taking user preferences and context into account impedes the manual configuration process, and thus, an efficient and automated procedure is required. To automate the configuration process, context-aware recommendation techniques have been acknowledged as an effective mean to provide suggestions to a user based on their recognized context. In this work, we propose a collaborative filtering method based on tensor factorization that allows an integration of contextual data by modeling an N-dimensional tensor User-Feature-Context instead of the traditional two-dimensional User-Feature matrix. In the proposed approach, different types of non-functional properties are considered as additional contextual dimensions. Moreover, we show how to self-configure software product lines by applying our N-dimensional tensor factorization recommendation approach. We evaluate our approach by means of an empirical study using two datasets of configurations derived for medium-sized product lines. Our results reveal significant improvements in the predictive accuracy of the configuration over a state-of-the-art non-contextual matrix factorization approach. Moreover, it can scale up to a 7-dimensional tensor containing hundred of configurations in a couple of milliseconds.

Analyzing and extracting features and variability from different artifacts is an indispensable activity to support systematic integration of single software systems and Software Product Line (SPL). Beyond manually extracting variability, a variety of approaches, such as feature location in source code and feature extraction in requirements, has been proposed for automating the identification of features and their variation points. While requirements contain more complete variability information and provide traceability links to other artifacts, current techniques exhibit a lack of accuracy as well as a limited degree of automation. In this paper, we propose an unsupervised learning structure to overcome the abovementioned limitations. In particular, our technique consists of two steps: First, we apply Laplacian Eigenmaps, an unsupervised dimensionality reduction technique, to embed text requirements into compact binary codes. Second, requirements are transformed into a matrix representation by looking up a pre-trained word embedding. Then, the matrix is fed into CNN to learn linguistic characteristics of the requirements. Furthermore, we train CNN by matching the output of CNN with the pre-trained binary codes. Initial results show that accuracy is still limited, but that our approach allows to automate the entire process.

Testing is a fundamental task to ensure software quality. Regression testing aims to ensure that changes to software do not introduce new failures. As resources are often limited and testing comprises a vast amount of test cases, different regression strategies have been proposed to reduce testing effort by selecting or prioritizing important test cases, e.g., code coverage (to ensure a sufficient testing depth). However, in system testing, source code is often not available creating a black-box system. In this paper, we introduce an automated, multi-objective test case selection technique in black-box systems using genetic algorithms. We define seven different objectives, based on meta-data, allowing a flexible test case selection for a variety of systems. For evaluation, we apply our technique on two different subject systems assessing the feasibility and suitability of our test case selection approach. Results indicate that our approach is applicable based on different data available and is able to outperform random test case selection and retest-all.

Preprocessor annotations (e.g., #ifdef in C) enable the development of similar, but distinct software variants from a common code base. One particularly popular preprocessor is the C preprocessor, cpp. But the cpp is also widely criticized for impeding software maintenance by making code hard to understand and change. Yet, evidence to support this criticism is scarce. In this paper, we investigate the relation between cpp usage and maintenance effort, which we approximate with the frequency and extent of source code changes. To this end, we mined the version control repositories of eight open- source systems written in C. For each system, we measured if and how individual functions use cpp annotations and how they were changed. We found that functions containing cpp annotations are generally changed more frequently and more profoundly than other functions. However, when accounting for function size, the differences disappear or are greatly diminished. In summary, with respect to the frequency and extent of changes, our findings do not support the criticism of the cpp regarding maintainability.

A common and simple way to create custom product variants is to copy and adapt existing software (a. k. a. the clone-and-own approach). Clone-and-own promises low initial costs for creating a new variant as existing code is easily reused. However, clone-and-own also comes with major drawbacks for maintenance and evolution since changes, such as bug fixes, need to be synchronized among several product variants. Software product lines (SPLs) provide solutions to these problems because commonalities are implemented only once. Thus, in an SPL, changes also need to be applied only once. Therefore, the migration of cloned product variants to an SPL would be beneficial. The main tasks of migration are the identification and extraction of commonalities from existing products. However, these tasks are challenging and currently not well-supported. In this paper, we propose a step-wise and semi-automated process to migrate cloned product variants to a feature-oriented SPL. Our process relies on clone detection to identify code that is common to multiple variants and novel, variant-preserving refactorings to extract such common code. We evaluated our approach on five cloned product variants, reducing code clones by 25 %. Moreover, we provide qualitative insights into possible limitations and potentials for removing even more redundant code. We argue that our approach can effectively decrease synchronization effort compared to clone-and-own development and thus reduce the long-term costs for maintenance and evolution.

Regression testing is the common task of retesting software that has been changed or extended (e.g., by new features) during software evolution. As retesting the whole program is not feasible with reasonable time and cost, usually only a subset of all test cases is executed for regression testing, e.g., by executing test cases according to test case prioritization. Although a vast amount of methods for test case prioritization exist, they mostly require access to source code (i.e., white-box). However, in industrial practice, system-level testing is an important task that usually grants no access to source code (i.e., black-box). Hence, for an effective regression testing process, other information has to be employed. In this paper, we introduce a novel technique for test case prioritization for manual system-level regression testing based on supervised machine learning. Our approach considers black-box meta-data, such as test case history, as well as natural language test case descriptions for prioritization. We use the machine learning algorithm SVM Rank to evaluate our approach by means of two subject systems and measure the prioritization quality. Our results imply that our technique improves the failure detection rate significantly compared to a random order. In addition, we are able to outperform a test case order given by a test expert. Moreover, using natural language descriptions improves the failure finding rate.

Design flaws in object-oriented programs may seriously corrupt code quality thus increasing the risk for introducing subtle errors during software maintenance and evolution. Most recent approaches identify design flaws in an ad-hoc manner, either focusing on software metrics, locally restricted code smells, or on coarse-grained architectural anti-patterns. In this paper, we utilize an abstract program model capturing high-level object-oriented code entities, further augmented with qualitative and quantitative design-related information such as coupling/cohesion. Based on this model, we propose a comprehensive methodology for specifying object-oriented design flaws by means of compound rules integrating code metrics, code smells and anti-patterns in a modular way. This approach allows for efficient, automated design-flaw detection through incremental multi-pattern matching, by facilitating systematic information reuse among multiple detection rules as well as between subsequent detection runs on continuously evolving programs. Our tool implementation comprises well-known anti-patterns for Java programs. The results of our experimental evaluation show high detection precision, scalability to real-size programs, as well as a remarkable gain in efficiency due to information reuse.

Developing and managing software variants is a key challenge in today's software development. Due to conflicting requirements, software is developed in multiple variants to satisfy the needs of individual customers. While software product lines allow the efficient development of a high number of variants, many projects in industrial software development start with few variants, where each variant is developed separately. Unfortunately, for an increasing number of variants, this clone-and-own approach becomes error-prone and unprofitable regarding synchronization of changes between variants. With VariantSync, we demonstrate a tool to reduce the gap between clone-and-own and product lines by automating the synchronization of software variants and simplifying a potential later transition to a product line.

Block-based modeling languages, such as MATLAB/Simulink or state charts, reduce the complexity inherent to developing large-scale software systems. When creating variants for largely similar yet different software systems, the common practice is to copy models and modify them to different requirements. While this allows companies to save costs in the short-term, these so-called clone-and-own approaches cause problems regarding long-term evolution and system quality as the relation between the variants of the resulting software family is lost so that the variants have to be maintained in isolation. To recreate information regarding the variants' relations, variability mining identifies common and varying parts of cloned variants but, currently, the respective algorithms have to be created for each target language individually. In this paper, we present a generalized method to instantiate variability mining for arbitrary block-based modeling languages. The identified variability information allows developers to understand the variability of their grown software family. This knowledge helps efficiently maintaining the variants and allows migrating from clone-and-own approaches to more elaborate reuse strategies, such as software product lines. We demonstrate the feasibility of our method by instantiating variability mining techniques for two block-based languages.

Code cloning has been reported both on small (code fragments) and large (entire projects) scale. Cloning-in-the-large, or forking, is gaining ground as a reuse mechanism thanks to availability of better tools for maintaining forked project variants, hereunder distributed version control systems and interactive source management platforms such as Github. We study advantages and disadvantages of forking using the case of Marlin, an open source firmware for 3D printers. We find that many problems and advantages of cloning do translate to forking. Interestingly, the Marlin community uses both forking and integrated variability management (conditional compilation) to create variants and features. Thus, studying it increases our understanding of the choice between integrated and clone-based variant management. It also allows us to observe mechanisms governing source code maturation, in particular when, why and how feature implementations are migrated from forks to the main integrated platform. We believe that this understanding will ultimately help development of tools mixing clone-based and integrated variant management, combining the advantages of both.

Code smells are established, widely used characterizations of shortcomings in design and implementation of software systems. As such, they have been subject to intensive research regarding their detection and impact on understandability and changeability of source code. However, current methods do not support highly configurable software systems, that is, systems that can be customized to fit a wide range of requirements or platforms. Such systems commonly owe their configurability to conditional compilation based on C preprocessor annotations (a. k. a. #ifdefs). Since annotations directly interact with the host language (e. g., C), they may have adverse effects on understandability and changeability of source code, referred to as variability-aware code smells. In this paper, we propose a metric-based method that integrates source code and C preprocessor annotations to detect such smells. We evaluate our method for one specific smell on five open-source systems of medium size, thus, demonstrating its general applicability. Moreover, we manually reviewed 100 instances of the smell and provide a qualitative analysis of its potential impact as well as common causes for the occurrence.

Software product lines have potential to allow for mass customization of products. Unfortunately, the resulting, vast amount of possible product variants with commonalities and differences leads to new challenges in software testing. Ideally, every product variant should be tested, especially in safety-critical systems. However, due to the exponentially increasing number of product variants, testing every product variant is not feasible. Thus, new concepts and techniques are required to provide efficient SPL testing strategies exploiting the commonalities of software artifacts between product variants to reduce redundancy in testing. In this paper, we present an efficient integration testing approach for SPLs based on delta modeling. We focus on test case prioritization. As a result, only the most important test cases for every product variant are tested, reducing the number of executed test cases significantly, as testing can stop at any given point because of resource constraints while ensuring that the most important test cases have been covered. We present the general concept and our evaluation results. The results show a measurable reduction of executed test cases compared to single-software testing approaches.

Program slicing is a common means to support developers in examining the source code with respect to debugging, program comprehension, or regression testing. While a vast amount of techniques exist, they are mostly tailored to single software systems. However, with the increasing importance of variable and highly-configurable systems, such as the Linux kernel, the number of software variants, subject to analysis, increases dramatically. Consequently, it is infeasible to apply slicing on each variant in isolation. To overcome this problem, we propose variability-aware slicing, a technique that can deal with source code variability, specifically conditional compilation as introduced by the C preprocessor. Particularly, we provide details of our variability-aware dependence analysis for program slicing, point out benefits of our slicing technique, and mention current limitations and future work.

The C preprocessor (CPP) is a simple and language-independent tool, widely used to implement variable software systems using conditional compilation (i.e., by including or excluding annotated code). Although CPP provides powerful means to express variability, it has been criticized for allowing arbitrary annotations that break the underlying structure of the source code. We distinguish between disciplined annotations, which align with the structure of the source code, and undisciplined annotations, which do not. Several studies suggest that especially the latter type of annotations makes it hard to (automatically) analyze the code. However, little is known about whether the type of annotations has an effect on program comprehension. We address this issue by means of a controlled experiment with human subjects. We designed similar tasks for both, disciplined and undisciplined annotations, to measure program comprehension. Then, we measured the performance of the subjects regarding correctness and response time for solving the tasks. Our results suggest that there are no differences between disciplined and undisciplined annotations from a program-comprehension perspective. Nevertheless, we observed that finding and correcting errors is a time-consuming and tedious task in the presence of preprocessor annotations.

In the recent past, the amount of high-dimensional data, such as feature vectors extracted from multimedia data, increased dramatically. A large variety of indexes have been proposed to store and access such data efficiently. However, due to specific requirements of a certain use case, choosing an adequate index structure is a complex and time-consuming task. This may be due to engineering challenges or open research questions. To overcome this limitation, we present QuEval, an open-source framework that can be flexibly extended w.r.t. index structures, distance metrics, and data sets. QuEval provides a unified environment for a sound evaluation of different indexes, for instance, to support tuning of indexes. In an empirical evaluation, we show how to apply our framework, motivate benefits, and demonstrate analysis possibilities.

The C preprocessor cpp is a powerful and language-independent tool, widely used to implement variable software in different programming languages (C, C++) using conditional compilation. Preprocessor annotations can used on different levels of granularity such as functions or statements. In this paper, we investigate whether there is a relation between code clones and preprocessor annotations. Specifically, we address the question whether the discipline of annotation has an effect on code clones. To this end, we perform a case study on fifteen different C programs and analyze them regarding code clones and #ifdef occurrences. We found only minor effects of annotations on code clones, but a relationship between annotations that align with the code structure (and code clones). With this work, we provide new insights why code clones occur in C programs. Furthermore, the results can support the decision whether or not it is beneficial to remove clones.

Some limitations of object-oriented mechanisms are known to cause code clones (e.g., extension using inheritance). Novel programming paradigms such as feature-oriented programming (FOP) aim at alleviating these limitations. However, it is an open issue whether FOP is really able to avoid code clones or whether it even facilitates (FOP-related) clones. To address this issue, we conduct an empirical analysis on ten feature-oriented software product lines with respect to code cloning. We found that there is a considerable number of clones in feature-oriented software product lines and that a large fraction of these clones is FOP-related (i.e., caused by limitations of feature-oriented mechanisms). Based on our results, we initiate a discussion on the reasons for FOP-related clones and on how to cope with them. We show by means of examples how such clones can be removed by applying refactorings.