{'fraction_non_alphanumeric': 0.016781083142639208, 'fraction_numerical': 0.0, 'mean_word_length': 5.188679245283019, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Measuring the superfluous functionality in software components

One of the drawbacks of a pragmatic, white box approach to the reuse of software is that reusable components often have more built-in functionality than is needed for a particular (re)usage scenario. This functionality either has to be invasively removed by changing the source code of the component, with the corresponding risk of errors, or has to be incorporated into a new project where it essentially pollutes the code base. While this may not be an immediate problem, over time such unneeded, polluting functionality can decrease the understandability of software and make it harder to maintain. The degree of superfluous functionality built into a component, when considered for a new use for which it was not initially intended, is therefore a useful metric which should be taken into account when choosing components to reuse. For example, it can be used as an input for a code search engine's ranking algorithm. In this paper we present a family of metrics for measuring the superfluous functionality within software components from the perspective of specific (re)use scenarios, describe how these metrics can be calculated, and investigate their utility as a differentiating measure to help developers choose which components to reuse.