Rochester Institute of Technology RIT Scholar Works

Presentations and other scholarship Faculty & Staff Scholarship

9-23-2018

Which Method-Stereotype Changes are Indicators of Code Smells?

Michael J. Decker Bowling Green State University

Christian D. Newman Rochester Institute of Technology

Natalia Dragan Kent State University

Michael L. Collard The University of Akron

Johnathan I. Maletic Kent State University

See next page for additional authors

Follow this and additional works at: https://scholarworks.rit.edu/other

Recommended Citation M. J. Decker, C. D. Newman, N. Dragan, M. L. Collard, J. I. Maletic and N. A. Kraft, "[Research Paper] Which Method-Stereotype Changes are Indicators of Code Smells?," 2018 IEEE 18th International Working Conference on Source Code Analysis and Manipulation (SCAM), Madrid, 2018, pp. 82-91, doi: 10.1109/ SCAM.2018.00017

This Conference Paper is brought to you for free and open access by the Faculty & Staff Scholarship at RIT Scholar Works. It has been accepted for inclusion in Presentations and other scholarship by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. Authors Michael J. Decker, Christian D. Newman, Natalia Dragan, Michael L. Collard, Johnathan I. Maletic, and Nicholas A. Kraft

This conference paper is available at RIT Scholar Works: https://scholarworks.rit.edu/other/959 Which Method-Stereotype Changes are Indicators of Code Smells?

Michael J. Decker Christian D. Newman Natalia Dragan Department of Computer Science Department of Software Engineering Departmnet of Management and Information Bowling Green State University Rochester Institute of Technology Systems Bowling Green, OH, USA Rochester, NY, USA Kent State University, Kent, OH, USA [email protected] [email protected] [email protected]

Michael L. Collard Jonathan I. Maletic Nicholas A. Kraft Department of Computer Science Department of Computer Science ABB Corborate Research The University of Akron Kent State University Raleigh, NC, USA Akron, OH, USA Kent, OH, USA [email protected] [email protected] [email protected]

Abstract— A study of how method roles evolve during the and the system as a whole. A number of researchers have lifetime of a software system is presented. Evolution is examined leveraged stereotypes for various applications by analyzing when the stereotype of a method changes. [9][10][11][12][13][14]. Two simple examples of stereotypes Stereotypes provide a high-level categorization of a method’s are accessor (e.g. getter) and mutator (e.g. setter). Accessor behavior and role, and also provide insight into how a method methods allow for information to be read from an object while interacts with its environment and carries out tasks. The study preventing modification of the object. Mutator methods allow covers 50 open-source systems and 6 closed-source systems. one to modify the state of an object. In the next section, we Results show that method behavior with respect to stereotype is present a complete set of stereotypes and definitions. highly stable and constant over time. Overall, out of all the history In the work presented here, we are interested in how the examined, only about 10% of changes to methods result in a stereotype of a particular method changes during the lifetime of change in their stereotype. Examples of methods that change stereotype are further examined. A select number of these types a system. In particular, we want to determine if a method’s of changes are indicators of code smells. stereotype changes often or rarely. What types of changes in stereotype are most common? Are some types of these changes Keywords—method stereotypes, software change, software hazardous? Or innocuous? Our goal is to determine what is the evolution, code smells, empirical norm, with regards to changes in stereotype, so we may let developers and project managers know when something is abnormal, and thus potentially a problem. I. INTRODUCTION To this end, we have undertaken an empirical study of the A typical, non-trivial, software system is in a constant state complete version history of 50 open-source C++ systems. This of evolution over its lifetime [1]. At points in this lifetime, its provides us with almost 1.4 million changes to methods. We design may degrade or be broken by the evolutionary change. also separately examined 6 closed-source systems with nearly This eventually requires developers to spend time redesigning 54K changes to methods. Each of the methods that change are parts (or the entirety) of the system. Code smells [2][3] are one examined over time and what happened to their (automatically indicator of poor design or design degradation. Thus, there is computed) stereotype is recorded. Our first goal is to examine research examining ways to automatically identify certain code the stability of method stereotypes during evolution. That is, do smells with the goal of warning users when a system’s design is method stereotypes change as methods change? potentially degrading [4][5][6]. Our second goal is to determine what types of changes from The work presented here takes a similar approach. That is, one stereotype to another stereotype are potentially hazardous. we are trying to understand what types of changes to a system Intuitively, a method should not change drastically from its are potentially hazardous to the design. Here, we are specifically original intent. If there is a drastic change in its role and/or interested in how individual methods change over time. While behavior this may be an indication of a problem. However, a change to an individual method will not typically degrade a clearly systems do evolve and the role of methods must evolve system’s design, changes to large sets of methods can. Hence, in some manner. There may also be changes that fix poor we empirically investigate and propose a relatively simple designs and these types of changes may be reflected in the abstraction and lightweight approach that indicates when a stereotype of a method. We seek to answer the following change is a potential problem. research questions: The granularity of change we are examining is at the level of • RQ1: Is a method’s stereotype stable as it evolves? a method. The abstraction we are using is the idea of method • RQ2: What types of method-stereotype changes occur? stereotypes [7][8]. Method stereotypes represent a rich • RQ3: Which method-stereotype changes are benign or abstraction of the role and behavior of a method within its class suspicious?

XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE To answer these questions, we perform three separate types identify non_const_get methods which, unlike a get method, can of analysis. First, we analyze stereotype changes in terms of the additionally mutate an object’s state (i.e., can have an additional change in behavior they represent and the consequences they stereotype from the Structural Mutator category). An alternative have on the source code. Then, we perform an empirical tool for stereotype identification [8] that works only for Java investigation on 50 open-source software systems. Finally, we programs is also available but appears to be less robust than finish with a manual investigation of method-stereotype StereoCode, hence the use of StereoCode. changes. We also examine 6 closed-source systems to see if the results are similar to the open-source code. The contributions of TABLE I. METHOD STEREOTYPE TAXONOMY. EACH STEREOTYPE this work are as follows: CATEGORY IS LISTED WITH ITS SET OF STEREOTYPES. • An empirical study that demonstrates that the stereotype Stereotype Stereotype Description of a method is very stable as it evolves within a system. Category • A set of defined stereotype transitions and their get Returns a data member. Returns Boolean value that is potential impact on a system’s design. predicate not a data member. Structural • A manual evaluation of potentially problematic Returns info about data Accessor property stereotype transitions. members. Returns information via a The paper is organized as follows. In Section II, we discuss void-accessor method stereotypes in detail. In Section III we discuss our parameter. set Sets a data member. motivation for investigating stereotype stability. In Section IV, Structural command Performs a complex change to we discuss the stability of method stereotypes and introduce a Mutator non-void-command the object’s state. taxonomy of method-stereotype changes. In Section V, we constructor, discuss how we collect data for an empirical and manual copy-constructor, Creates and/or destroys Creational investigation. In Section VI, we present the results of an destructor, objects. empirical and manual investigation of the method stereotypes factory and relate it to the taxonomy. Finally, in Sections VII and VIII, Works with objects the threats to validity and conclusion are provided. collaborator (parameter, local or return Collaborational value). Changes only an external II. METHOD STEREOTYPES controller object’s state (not this). We now provide a brief introduction to method stereotypes. Does not read/change the The work of Dragan et al. [7] [15][16] introduces a taxonomy incidental object’s state. No calls to for method stereotypes, which we show in TABLE I. A method other class methods. Degenerate Does not read/change the stereotype concisely represents behavioral aspects of a method. stateless object’s state. One call to Method stereotypes are separated into five broad categories: other class methods. Structural Accessors – query the state of an object on which it is empty Has no statements. called; Structural Mutators – modify the state of an object on which it is called; Creational – create/provide new objects; III. MOTIVATION AND RELATED WORK Collaborational – work on objects pertaining to classes other Method stereotypes have been shown to be a useful and than itself; and Degenerate – no use of the object’s state and powerful abstraction of a method’s role and behavior. often no statements. Stereotypes have been used for numerous applications, The individual stereotypes indicate a refinement of the broad including generating natural-language summaries [9][18], behavior described by the category. As an example, stereotypes feature location [11], detecting potential design flaws [12], in the general category Structural Accessor query an object’s categorizing identifiers [13], and generating commit messages state, while the stereotype predicate more specifically returns a [14]. However, there has been no work examining the overall computed Boolean value. This Boolean characterizes some behavior of stereotypes and how they change as a system information about the state of the object on which the predicate evolves. The closest to this work is Dragan et al. [16], which method is called. examines only added and deleted methods to categorize Methods may be labeled with one or more stereotypes. That commits. Additionally, Dragan [19] also examined the is, methods may have a single stereotype from any category and distribution of method stereotypes in a few releases (~20) of two may also have additional stereotypes from other categories. For systems and found the distribution of method stereotypes to be example, a get collaborator is a get (accessor) method that uses fairly consistent for one system and unstable for the other. an object of another class (e.g., return type). In addition, while The primary advantage to method stereotypes is that they considered an anti-pattern, a method can both query an object’s summarize the role/responsibility of a method. Understanding state (Structural Accessor) and modify that state as well how stereotypes evolve lays a stronger theoretical groundwork (Structural Mutator). for current and any future research relying on stereotypes. It also A freely available tool (see https://github.com/srcML/ provides a basis on top of which research can build stereocode), StereoCode, analyzes and re-documents C++ improvements and additions to the stereotype model. To be source code (using srcML [17]) with the stereotype information specific, one way of measuring how well a model fits the data it for each method. StereoCode reports a superset of the is measuring is to analyze how well the model indicates normal stereotypes defined in TABLE I. For instance, a get method is behavior and how well it can indicate abnormal behavior. In this required to be const and thus cannot be both a Structural case, stereotypes are the model and methods are the data. Accessor and Structural Mutator. However, the tool will also The goal is to determine if changes in stereotype indicate a IV. EVOLUTION OF A METHOD’S STEREOTYPE benign or suspicious change to the stereotype’s method. As stereotypes describe a method’s behavior and role at a Showing that stereotypes do not typically change in response to high level, we are able to use changes in a method’s stereotype method changes lends more credibility to stereotypes as a good to theorize about the consequences of such changes. We define model of the innate qualities of methods if we assume a a stereotype transition as a change in a method’s stereotype method’s behavior does not typically change drastically as a caused by changes made to the method. Stereotype transitions system evolves. Under this assumption, we then need to can be indicators of design improvement or degradation. We additionally show that when a stereotype changes due to a use suspicious for a transition that indicates degradation and change to a method, this change indicates some sort of important benign otherwise (improvement or neutral). For example, a activity. That is, if lack of change in stereotype indicates normal change that causes a C++ method to transition from being a behavior then a stereotype change indicates abnormal behavior. non_const_get to a get is an example of a benign transition, as it This abnormal behavior may indicate a poorly designed method forbids modification of object state by the callee and allows or inappropriate/incorrect changes to a method. const objects to use the method. Thus, it improves design by The result of this work contributes the following: 1) data on restricting undefined behavior and makes the system easier to how method stereotypes evolve, which will support future maintain. If the opposite occurs, a transition in stereotype from research, 2) a basis to improve stereotypes as a model of a get method to a non_const_get method, we have an example methods and as their role in the context of a system, and 3) a of a suspicious change that indicates a degradation in the design preliminary study of how stereotypes may be used to alert of the system (i.e., code smell). Note, the addition of a developers of code smells and suspicious changes in general. non_const_get method is sometimes necessary in C++ and Towards this, we first explore the question of whether therefore valid. However, a change which replaces a const stereotypes generally change when changes are made to accessor (which is necessary for const objects) with a methods (RQ1). In order to answer this, we mine the software non_const_get method indicates that development is loosening repositories (complete history) of over 50 open-source and restrictions on previously forbidden behavior, in addition to closed source systems (Section V and VI). We then use this in limiting the objects on which the method can be invoked. This combination with a taxonomy (presented in Section IV) to type of change must be highlighted and reviewed, hence we term investigate methods whose stereotypes do change, in order to it suspicious. see the type of changes that occur (RQ2) and whether those TABLE II. contains our taxonomy of stereotype transitions. changes are benign or suspicious (RQ3). The overall goal is to This taxonomy is not meant to be complete, but to highlight understand consequences of changes in method stereotypes. important transitions that have well-defined consequences. For As a goal of the presented work is to evaluate if changes in each entry in the taxonomy there is a name/type of that method stereotype can be used to indicate the introduction of classification of transitions, what types of stereotypes are code smells, previous work on code smells and their detection is involved in the transition, a description of the transition type, relevant. Mantyla et al. [20] present a taxonomy that categorizes and lastly notes about the implications and significance of such similar bad smells and presents findings from an empirical study transition and whether such transitions are generally benign or of using smells to detect software quality. Rani and Chhabra suspicious. Transitions that are not part of the taxonomy such [21] present an empirical study on the distribution of select code as other changes within the same category are considered smells over different versions of software projects. Tufano et al. benign. This provides a partial answer to RQ2, and it provides [2][22] investigate the change history of 200 open-source a start for answering RQ3. We investigate this further in a projects to identify when code smells are introduced and if they manual investigation described in a following section. are ever removed. The major difference between these works The main goal of this study is to investigate how often and ours is that they tend to target very specific forms of code stereotypes change (i.e., RQ1), and if they change, the and design smells, while our work focuses on the behavior of the frequency and patterns of changes, i.e., how often and what do methods (as represented by method stereotypes) themselves. they change to. To do this, the entire history of multiple systems In [23], the use of change history was explored to detect code is analyzed, and data collected on changes (or lack thereof) to smells. Similar to this work, they use structural changes over method stereotypes. As the transition categories provided in time to identify a set of code smells defined within the paper. TABLE II. are primarily conjectural, an investigation into the The primary difference between their work and ours is that they changes that induce a change in method stereotype is correlate specific types of changes and change patterns to the investigated manually (Section VI.C). smell categories provided in their work whereas we do not do code-level change patterns, but method-behavior level. V. DATA COLLECTION Additional code smell detectors include: JDeodorant [24][25][26][27], Moha et al. [5] Sahin et al. [28], and Mansoor To investigate changes in method stereotypes, fifty open- et al. [29]. These detectors have been used (such as in [21] and source software systems, given in TABLE III. were selected for [2][22]) or can be used to investigate the evolution of code study. The subject systems are selected using the following smells. The work provided here provides a complimentary and criteria: 1) C++ is the primary language, 2) a minimum of 500 novel view based on the behavior represented by method commits, 3) representative ranges of project size in terms of stereotypes. Additional work on the mining software number of commits, and 4) representative sample of domains. repositories includes commit categorization [30][31][32], bug The number of revisions (center column) are for each system prediction [12], and topic analysis [33]. and are non-merges that contain a modified C++ file.

TABLE II. TAXONOMY OF IMPORTANT STEREOTYPE TRANSITIONS. EACH TRANSITION TYPE HAS A STEREOTYPE CATEGORY, A DESCRIPTION WHICH INCLUDES THE METHOD STEREOTYPES THAT ARE PART OF THE TRANSITION, AND THE IMPLICATIONS OF THE TRANSITIONS TO THE DESIGN OF THE SYSTEM. Stereotype Transition Type Description Design Implications Category • Methods that cannot be classified lack a clear abstraction Move to/from Method transitioned to/from Unclassified • To unclassified (suspicious) Unclassified Unclassified • From unclassified (benign) • From Accessor to non_const_get breaks ability use on Move to/from Method transitioned between Structural constants/degrades design (suspicious) Non_const_get non_const_get and another Accessor • From non_const_get to Accessor increases information hiding. Method Accessor probably should have always been Accessor (benign) A method adds a Collaborational Add • Addition of Collaborational indicates increased dependency to other stereotype or transitions from Collaborational object(s) (benign, but suspicious in large numbers) another category to Collaborational Collaborational A method removes Collaborational Remove • Removal of Collaborational indicates decreased dependency to other or transitions from a Collaborational object(s) (benign) Collaborational to another category A method adds a Degenerate • Method’s functionality has been diminished Add Degenerate stereotype or transitions from • Indicates method does not have enough responsibility and consider another category to a Degenerate removal (suspicous) Degenerate A method removes a Degenerate • Degenerate methods do not provide enough functionality Remove stereotype or transitions from a • Removal is generally a positive (benign) Degenerate Degenerate stereotype to one of another category • Indicates addition of more functionality or increased complexity A change from Structural Cross Stereotype Accessor, Structural Mutator, and • Massive change to function behavior Boundaries Creational to a different one of • Change is suspicious and should be investigated those categories • Method has too much responsibility Multiple • Presence is possible code smell Categories Method that has multiple • Transition that adds additional method stereotypes indicates degrade in Add/Remove/ stereotypes from at least two of the design (suspicous) Replace following: Structural Accessor, Categories • Transition that removes stereotypes indicates a design improvement Structural Mutator, and Creational (benign) • When categories are replaced with others indicates poor design (suspicous)

The entire commit history of all systems is investigated files are ignored since they can only contain new or removed providing a total of 445,255 revisions. The right-column in methods. For similar reasons, copied and renamed files are also TABLE III. contains the location of repository. When the ignored. In short, we only use file reported by git-log as repository location is not a fully qualified URL, the repository modified. In addition, git-log is set to not report merge comes from GitHub and has the following complete location: revisions. As git-log reports modified files irrespective of https://github.com/{Location}.git. The data collection process contents, when processing the report provided by git-log, the consists of the following parts: Python program uses file extensions to identify C++ files and 1. Identification of all revisions and the files changed in filter out non-C++ files. The typical file extensions for C++ are those revisions. used (e.g., .cpp, hpp) with .h (a typical C-language extension that 2. Application of a syntactic differencer to the original and is still used in C++) treated as C++ code. Then, the Python modified version of all changed C++ files to generate a program runs srcDiff on all the identified modified C++ files for fine-grained change log of each revision. each revision and generates a single change log for each revision 3. Analysis of the change logs to locate changed methods. (part 2). 4. Collection of the original and modified stereotype of Once the change log is created for each revision, the data can each changed method. be examined for stereotype changes (parts 3 and 4). To examine, More specifically, data is collected for each system in the the change logs, a separate Python program we developed is following manner. First, a local clone of the repository is made. used to parse the change log, identify and collect the signatures Next, the syntactic difference of every modified C++ file for of changed methods (part 3), and then apply StereoCode to each revision of the default branch is computed (parts 1 and 2) compute the original and modified method stereotypes for the using srcDiff [34]. In order to generate the change logs for each changed method (part 4). A method is identified as changed and revision, a Python program generates a list of each revision and the signature collected if 1) it contains a change (added, deleted, the modified C++ files contained within each of those revisions or modified) to the text of the method, 2) the text changed is not (part 1). To generate this list, the Python program uses the whitespace or part of a comment, and 3) the method itself is not command git-log. With the correct options, git-log reports all inserted or deleted. modified files and their associated revisions. Since we are Whitespace and comments (i.e., non-source code) changes interested in changes to existing methods, added and deleted are ignored, as they are non-functional/stylistic changes. In addition to the signature, for each changed method, the line same ID information collected for the changed methods (line number, class, and file containing the method are also collected. number, file name, class name, and method signature). This is These additional attributes are collected to generate a unique ID. used to lookup the original and modified stereotypes. After information for each changed method is collected, the StereoCode is applied to the entire file as opposed to just the original and modified source code versions for that revision are each version of the method to avoid error due to any dependency converted to srcML using tools provided at srcML.org. StereoCode may have on contextual information. Finally, information is recorded in two ways. First, each TABLE III. SELECTED SOFTWARE SYSTEMS ORDERED BY NUMBER OF stereotype and ID information pair is recorded. Second, running REVISIONS. KLOC IS THE CODE OF THE MOST RECENT VERSION, # REV IS totals on the counts of the number of times each stereotype NUMBER OF REVISIONS WITH MODIFIED C/C++ FILES. LOCATIONS HAVE A URL OF HTTPS://GITHUB.COM/{LOCATION}.GIT, EXCEPT FOR CLANG. transition occurred and when each stereotype did not change are updated. All programs written for the data collection process System KLOC # Rev Location were tested and verified for accuracy. kokkos 141 745 kokkos/kokkos tera 114 832 baidu/tera VI. RESULTS json 62 1,049 nlohmann/json griefly 21 1,074 griefly/griefly Data was collected from all investigated systems. Empirical CRYENGINE 2,337 1,092 CRYTEK/CRYENGINE results are presented in Section A. In Section B we compare the MultiMC5 73 1,267 MultiMC/MultiMC5 results of Section A to that from six additional closed-source ChaiScript 33 1,312 ChaiScript/ChaiScript systems, and the manual investigation is presented in Section C. Mantella 3 1,320 Mantella/Mantella GamePlay 300 1,354 gameplay3d/GamePlay A. Empirical Investigation Plasma 686 1,395 H-uru/Plasma antimony 106 1,737 mkeeter/antimony Results on all method changes for all systems is now Rcpp 109 1,947 RcppCore/Rcpp presented. The complete dataset is available at engine 155 2,078 flutter/engine http://www.sdml.cs.kent.edu/stereodiff/. The data is analyzed oiio 165 2,445 OpenImageIO/oiio on all systems as a whole as well as on each system individually. rdkit 252 2,474 rdkit/rdkit Due to space restrictions, we report the total occurrences out of distortos 880 2,498 DISTORTEC/distortos all systems and the median percentage. The median percentage nix 39 2,704 NixOS/nix is computed by calculating the percentages individually for each CTK 252 2,823 commontk/CTK system and then taking the median. We computed median irods 225 2,860 irods/irods citra 107 2,908 citra-emu/citra because the data is not uniform. The number of BansheeEngine 344 3,058 BearishSun/BansheeEngine revisions/method changes for each system is not uniform (some newton-dynamics 1,678 3,124 MADEAPPS/newton-dynamics systems contribute significantly more) and computing gnuradio 262 3,191 gnuradio/gnuradio percentages of on all systems collectively can be affected by this folly 238 3,277 facebook/folly disproportion. However, for the data we collected, the results supertux 97 4,283 SuperTux/supertux are similar with either method. Dlib 479 4,366 davisking/dlib Over all systems, there is a total of 1,361,348 changes to ola 211 4,470 OpenLightingProject/ola methods. The vast majority, 1,233,645 (89.9%), of the changes tfs-old-svn 89 4,665 otland/tfs-old-svn Urho3D 959 5,225 urho3d/Urho3D to methods resulted in no change in the stereotype. That is, the ogre 639 5,280 OGRECave/ogre stereotype of a method is very stable over time. Of the method appleseed 304 5,369 appleseedhq/appleseed changes in these systems, only 127,603 (10.1%) result in a bitcoin 148 5,785 bitcoin/bitcoin change in stereotype, with the percentage on individual systems openFrameworks 190 6,620 openframeworks/openFrameworks ranging from 4.5% to 29.0%. codeblocks 315 7,484 jenslody/codeblocks TABLE IV. presents the top-ten most commonly changed codelite 812 7,918 eranif/codelite methods grouped by their stereotype. In all cases, the changes QuantLib 497 8,526 lballabio/QuantLib that did not impact the stereotype. Of all method changes, the stellarium 238 8,677 Stellarium/stellarium Natron 702 10,064 MrKepzie/Natron percentage drops sharply from 41.9%, for command opencv 937 11,328 opencv/opencv collaborator, down to 0.7% for unclassified, with 50% either cocos2d-x 997 13,890 cocos2d/cocos2d-x command collaborator or non_void_command collaborator. ppsspp 483 15,272 hrydgard/ppsspp The top-ten method changes where the stereotype changed kdevelop 162 16,663 KDE/kdevelop (transitions) are shown in TABLE V. We found over 2,000 Dealii 2,463 20,340 dealii/dealii unique transitions in total, many of which occur a small number blender 1,213 24,215 git://git.blender.org/blender.git of times. For the most part, the transitions are benign according xbmc 980 25,280 xbmc/xbmc to the taxonomy (e.g., unclassified to command). The main type Mongo 3,122 26,345 mongodb/mongo Qt 5,228 28,069 qt/qt of transition that is suspicious is non_void_command swift 719 30,343 apple/swift collaborator to property collaborator which indicates a cgal 1,678 39,583 CGAL/cgal significant deviation in behavior. Clang 1,571 56,631 http://llvm.org/git/clang Also of note in TABLE V. the percentage of each transition Total 33,820 445,255 is very low (i.e., < 1%). Collectively, out of all method changes, stereotype transitions only occur 10.1% of the time, with each Then, StereoCode is used on the original and modified code individual transition type occurring with a small percentage. to compute the stereotype of each method. StereoCode reports With this, we can now answer RQ1. Method stereotypes, as a these in a CSV format containing the method stereotype and the whole, change infrequently due to changes to methods and thus, classes in a system over time (the remaining pure insert and a method’s stereotype is very stable over evolution. delete data that is not shown here does not offset this trend). The remaining times a stereotype transition occurred it TABLE IV. TOP TEN MOST COMMON CHANGES TO METHODS THAT DID completely changed from one stereotype to another: 24,859 NOT CHANGE THE STEREOTYPE (GROUPED BY STEREOTYPE), MEDIAN OF THE PER-SYSTEM PERCENT OUT OF ALL METHOD CHANGES, AND THE NUMBER (19.8%), or partially-changed (one or more stereotypes replaced CHANGED. with one or more other stereotypes with at least one stereotype remaining in common to both): 35,469 (27.4%). TABLE VIII. Stereotype Median % Count command collaborator 41.9% 595,085 and TABLE IX. provide the top-ten completely changed method non_void_command collaborator 8.1% 164,289 stereotypes and partially-changed stereotypes, respectively. command 4.9% 65,473 For TABLE VIII. the change from the original stereotype to property collaborator 4.1% 76,635 the modified stereotype, the median of the per-system collaborator 4.0% 63,473 percentage (with percent individually out of total amount of get collaborator 1.7% 23,614 transitions in that system), and the number of occurrences is void_accessor collaborator 1.7% 49,312 given. The most frequently completely changed stereotypes are non_void_command collaborator 1.0% 40,183 unclassified to command (benign), set to command (within same factory predicate collaborator 1.0% 21,425 stereotype category), and unclassified to collaborator (benign). unclassified 0.7% 10,391 Out of all the top ten, the only suspicious transitions are those that are no longer able to be classified by StereoCode TABLE V. TOP TEN STEREOTYPE TRANSITIONS OUT OF OVER 2,000 (unclassified), which may indicate that the methods have UNIQUE POSSIBLE TRANSITIONS. THE STEREOTYPE OF THE METHOD CHANGED become convoluted, lacking a clear abstraction (e.g., long FROM ITS ORIGINAL STEREOTYPE TO THE MODIFIED STEREOTYPE, WITH THE MEDIAN OF THE PER-SYSTEM PERCENT OUT OF ALL METHOD CHANGES. method code smell).

Original Stereotype Modified Stereotype Median % Count TABLE VI. TOP TEN DELETED STEREOTYPES. MEDIAN % IS THE MEDIAN command OF THE PER-SYSTEM PERCENT WITH THE PERCENT INDIVIDUALLY OUT OF ALL command 0.5% 6,327 collaborator TRANSITIONS IN THAT SYSTEM. command collaborator 0.5% 7,633 Deleted Stereotype Median % Count collaborator command collaborator 5.3% 8,496 collaborator 0.3% 4,761 collaborator stateless 5.1% 7,498 command command 3.4% 4,859 command 0.3% 4,358 collaborator non_void_command 1.4% 2,283 non_void_command non_const_get 1.0% 1,891 collaborator 0.1% 2,407 collaborator collaborational_command 0.7% 1,280 command factory 0.5% 1,479 set collaborator 0.1% 1,907 collaborator empty 0.1% 356 unclassified command 0.1% 1,519 set 0.1% 269 non_void_command collaborational_command stateless 0.1% 213 collaborator 0.1% 1,645 collaborator set command 0.1% 1,567 TABLE VII. TOP TEN INSERTED STEREOTYPES. MEDIAN % IS THE MEDIAN non_void_command OF THE PER-SYSTEM PERCENT WITH THE PERCENT INDIVIDUALLY OUT OF ALL property collaborator 0.1% 1,889 collaborator TRANSITIONS IN THAT SYSTEM.

In order to answer RQ2, let us now take a closer look at Inserted Stereotype Median % Count stereotype transitions. Over, 65% of the time (median, with collaborator 10.1% 12,532 command 5.5% 7,705 totals of 1,245/1,742) that a non_const_get method changed stateless 3.6% 5,263 stereotype, it changed to a get. In fact, it is more common for a non_void_command 2.4% 3,618 non_const_get method to change into a get method, as it is to non_const_get 0.8% 1,423 remain a non_const_get (i.e., individually it is not stable). The collaborational_command 0.6% 827 opposite (get to non_const_get) is exceedingly rare (22 total property 0.5% 1,037 instances over all projects and revisions). That is, get methods factory 0.3% 1,000 are mistakenly written as non_const_get methods and then predicate 0.2% 415 set 0.1% 220 corrected at a later date. When a method-stereotype transition occurs, 37,183 In TABLE IX. the most common partially-changed (29.7%) of the time, one or more stereotypes are inserted and stereotypes are set with command (benign) and 30,092 (22.2%) of the time one or more stereotypes are deleted. non_void_command with property (suspicious as it may be A summarization of the top-ten deleted and inserted groups of adding a missing const or indicate a more serious problem). The stereotypes are in TABLE VI. and TABLE VII. respectively. In remainder are largely partially-changed from within the same both, the stereotype inserted or deleted is given with the median category (benign) with the exception of empty to command and of the per-system percent, and the number of occurrences. For non_const_get to get (benign); and command to void-accessor, both, the most common insertion or deletion is that of a single which crosses categories (suspicious). stereotype, with collaborator being most common. When just In summary, methods do not change stereotype very often. considering method stereotypes that purely inserted or deleted When they do change, most of the frequent types of changes are stereotypes, this points to increased collaboration between of relatively little concern. There are, however, a few among the top-ten that are worth investigating. Due to their relative rarity, (57/132) of the time. In contrast, in the open-source systems get an automatic detection and reporting/alerting tool would be of did not change (i.e., is stable) 70.9% (4,781/6,821) of the time great use. Such a tool can easily be integrated into an IDE or and non_const_get is stable 31.9% (1,396/3,138). Although versioning system. non_const_get transitioned to get 40/132 times, unlike the open-

TABLE VIII. TOP TEN COMPLETELY CHANGED STEREOTYPES. FROM THE source data, the median of the per-system percent is zero. More ORIGINAL TO MODIFIED STEREOTYPE. MEDIAN IF OF THE PER-SYSTEM PERCENT consistent with the open-source systems, although get is not ( PERCENT OF ALL TRANSITIONS IN THAT SYSTEM). stable in closed systems, it never changed to a non_const_get. Original Modified Regarding how method stereotypes change, when a Median % Count Stereotype Stereotype stereotype transition occurs, it is completely changed 16.7% unclassified command 1.2% 1,519 (682) of the time; only consisted of deleted stereotypes 23.2% set command 1.2% 1,567 (1140) of the time; only consisted of inserted stereotypes 40.9% unclassified collaborator 0.8% 1,077 (1,717) of the time; and had stereotypes partially changed 20.5% command unclassified 0.7% 955 (1,270) of the time. In comparison to the open-source systems, command set 0.6% 856 the median of inserting new stereotypes is more frequent by over non_const_get get 0.5% 1,245 collaborator unclassified 0.3% 890 10% of the median values while partial/complete change of stateless unclassified 0.2% 506 stereotypes medians are less (~6.9%/~3.1%). command unclassified 0.2% 420 TABLE X. CLOSED SOURCE SYSTEMS IDENTIFIED WITH ANONYMOUS collaborator NAMES. KLOC IS C++ CODE FOR THE MOST RECENT VERSION INVESTIGATED command USING WC, AND # REV IS NUMBER OF REVISIONS WITH MODIFIED C++ FILES. empty 0.2% 531 collaborator System KLOC # Rev EC 295 1,539 TABLE IX. TOP TEN PARTIALLY-CHANGED STEREOTYPES. MEDIAN IS OF THE PER-SYSTEM PERCENT (PERCENT OF ALL TRANSITIONS IN THAT SYSTEM). FASA 174 1,546 G 430 1,969 Original Stereotype Modified Stereotype Median % Count H 654 5,359 set command 1.4% 1,907 On 2,046 34,427 non_void_command property 1.3% 2,500 Op 995 315 command non_void_command 1.1% 1,519 Total 4,595 45,155 get property 0.9% 1,861 command set 0.9% 1,051 TABLE XI. TOP TEN MOST COMMON CHANGES TO METHODS THAT DID NOT CHANGE THE STEREOTYPE (GROUPED BY STEREOTYPE) FOR THE CLOSED- non_void_command command 0.8% 3,003 SOURCE SYSTEMS, MEDIAN OF THE PER-SYSTEM PERCENT IS OUT OF ALL property get 0.8% 1,212 METHOD CHANGES, AND THE NUMBER CHANGED. non_const_get get 0.6% 1,344 command void_accessor 0.5% 1,147 Stereotype Median % Count empty command 0.4% 895 command collaborator 38.8% 22,476 non_void_command collaborator 7.4% 17,207 B. Closed Systems command 4.9% 1,535 We additionally performed an empirical study of 6 closed- collaborator 4.1% 1,597 source systems (TABLE X. ) to understand generalizability of property collaborator 1.0% 229 non_void_command collaborator the open-source results. Among the 53,876 method changes in 0.7% 360 the 6 closed-source systems, 49,067 (86.7%) do not change factory non_const_get collaborator 0.6% 407 method stereotype and 4,809 (13.2%) do change method set collaborator 0.5% 215 stereotype (varying between 0-20%). The number of transitions unclassified 0.4% 224 in the closed systems is slightly higher, however, a larger collaborational_command collaborator 0.4% 439 selection of systems is needed to see if this trend holds. When both data sets are combined, less than 10.4% of all method Considering instances where the only a change in stereotype changes resulted in a method-stereotype change. is the insertion or deletion of one or more stereotypes, the closed Similar patterns are found for method changes that do not systems (similar to open-source systems) show a larger increase change method stereotype (TABLE XI. ). That is, a few in collaborator indicating increased collaboration. In contrast, stereotypes (first three are identical to those in open-source the closed systems have less variability in what stereotypes are system) occur with higher-frequency and the values drop inserted/deleted, with only 7/9 types occurring in the closed quickly. Likewise, all stereotype transitions are uncommon systems with a median greater than zero (open-source has 13 (<1%) with 8/10 stereotypes in common between the open- deleted and 17 inserted). source and closed systems (although in a different order). Also Similar to the open-source systems, the majority of the top- consistent with the open-source results, all but one transition is ten completely changed stereotypes are benign except two that benign. The one suspicious transition changed the method to be are not able to be classified (command to unclassified and both an accessor and mutator (non_void_command collaborator collaborator to unclassified). Likewise, partial changes are to non_void_command non_const_get collaborator). similar and mostly in the same category (benign). There are two As for get and non_const_get methods, as in the open-source other benign transitions (non_const_get to get and stateless to systems non_const_get is not stable (i.e., changes stereotypes command), and two suspicious transitions (non_void_command frequently). However, both are even more unstable than in the to non_const_get and command to empty). open-source systems. get methods did not change 15.7% Ultimately, there is some variation in the specific details of (20/58) of the time and non_const_get did not change 14.3% the two data sets. It is worth investigating in the future if a larger set of closed systems will produce results more consistent with A benign change is typically a neutral change or one that the open-source systems. However, although there are fixes a bug or code smell. Suspicious change is a change that is differences between the two data sets, the conclusions are clearly wrong or indicates a problem with the function. With largely the same: stereotypes transition occur infrequently, and corrections for the one change counted twice, 32% of changes when they do, few among the top-ten that are worth in method stereotype are suspicious, while 68% are benign. investigating. Thus, automatic detection and reporting will also In agreement with the taxonomy in TABLE II. From be valuable to closed systems. Non_const_get (convert from non_const_get to get), Remove Collaborational, Remove Degenerate, and Other are benign C. Manual Investigation indicators. The one instance of stereotype becoming In Section IV, we presented a taxonomy on the consequences unclassified is suspicious (method is poorly designed). Cross of a change to a method’s stereotype. In Section VI.A, we show Stereotype Boundaries, and Add Categories/Remove Categories that method stereotypes as a whole are stable with regards to (both those that become ones and those that lost the multiple method change with a method’s stereotype changing 10% of the categories) are mixed. That is, the method-stereotype change time in the 50 open source systems we examined. In addition, belonging to the Cross Stereotype Boundaries and the most frequent changes in method stereotype are generally Add/Remove/Replace transition types are indicators of problems safe and unsuspicious. with the method design or change, but only a portion of the time. In order to answer RQ3, we describe the results of a manual TABLE XII. SUMMARY OF MANUAL INVESTIGATION. FOR EACH METHOD- investigation of stereotype transitions. The approach taken is as STEREOTYPE TRANSITION TYPE THE TABLE STATES THE OVERALL NUMBER OF follows. First, a list is constructed containing all the method- OCCURRENCES. THIS IS BROKEN INTO NUMBER AND PERCENTAGE OF stereotype transitions that occur in the subject systems (TABLE OCCURRENCES FOR BOTH SUSPICIOUS CHANGES (I.E., SHOULD BE III. ) and the frequency for each is computed. Based on the INVESTIGATED FURTHER) AND BENIGN CHANGES (I.E., ARE OF NO CONCERN).. Overall Suspicious Benign behavior of method-stereotypes as described by Dragan et al. Type [8], an author who is an expert on method stereotypes examined # # % # % every method-stereotype transition (the expert had no To Unclassified 1 1 100% 0 0% knowledge of TABLE II. ) and they noted all the transitions that From Non_const_get 1 0 0% 1 100% Remove Collaborational 1 0 0% 1 100% should be investigated (i.e., was a possible code smell). Remove Degenerate 2 0 0% 2 100% Then, for each transition that occurred more than ten times Add Categories 8 4 50% 4 50% in the revision history of all 50 systems, a separate expert Remove Categories 4 2 50% 2 50% developer examined an instance of each of the method- Cross Stereotype 11 4 36% 7 64% stereotype transitions noted previously. For each instance, Boundaries detailed notes are taken about the change in method stereotype Other 6 0 0% 5 100% Total 33 11 32% 23 68% and the source code modified. When necessary, additional information is consulted such as related commits and their Fig. 1 and Fig. 2 give examples of a benign change and changes. This information is then used to make a determination suspicious change, respectively. For both figures, the method is of whether the change in method stereotype is of benign (no annotated with the changes in a unified-view. Inserted code is concern/positive) or suspicious (the method change is worth marked with a green background color, while code common to inspection by a developer) such as when the change to the both versions is left with a plain-white background. No deleted method is clearly wrong or revealed issues with the design and code is present in the examples. maintainability of the method/class. In Fig. 1, the developer makes a non_const_get method into This type of manual investigation is a slow and tedious a const get method, thus disallowing any indirect modification process. In order to make the investigation process more to the class data member and making the system easier to manageable, a syntactic source-code difference (i.e., srcDiff) maintain. In agreement with the taxonomy, we regard this as a supporting a unified view of changes and StereoCode were used benign change. to examine the changed methods. In Fig. 2, the developer makes an initialize method const, In total, 33 method-stereotype changes were examined in however, to make it compile, the developer also made several this level of detail. The investigation took approximately 20- data members of the class mutable, and thus making the system person hours. TABLE XII. presents a summary of the results more difficult to maintain. To make matters worse, a comment with each of the stereotype transitions grouped according to the by the developer reveals that they were baffled that the code taxonomy presented in Section IV. Other consists of worked previously. Clearly, this individual does not understand insignificant changes not included in the taxonomy (four the language concepts of const or mutable very well. This is an instances of changes within the same stereotype category and obvious mistake. In agreement with the taxonomy, we regard one command collaborator to collaborator). In addition, one this as a suspicious change. method change included both the Cross Stereotype Boundaries From this, we can conclude that although not perfect, certain and Multiple Category Stereotype, this is counted as part of both categories of method-stereotype changes (To Unclassified, (hence the count adds to 34 but one method is in the table twice Cross Stereotype Boundaries, and Add/Remove/Replace and we give 33 as the total). Categories) can be useful indicators for method-design For each of the categories present, a count of the number of problems or inappropriate method changes. Since changes in transitions belonging to those categories along with a count and method stereotype are uncommon (with specific categories percentage of the number of times those changed methods are being even less common), investigation by a developer will not benign or suspicious. require substantial time. From the manual investigation, we note that a finer-grained Some of the projects have code committed that is auto- categorization may produce more accurate predictions. For generated by some tooling. Auto-generated files may exist example, many of the Cross Stereotype Boundaries did so throughout the history of a project or may appear and disappear because method constness is added/removed. The addition of at any point in the history of the software. For the most part, we const, allowed StereoCode to make a correct assessment of are uninterested in changes to auto-generated code, however, as behavior and are benign changes, while the removal of const is they can appear at any point in history, they can be difficult to suspicious. That is, refining Cross Stereotype Boundaries into identify. Investigation into auto-detection of all generated files cases where adding const or removing const will increase through the history of projects is a valid research topic. In our prediction ability. Similar types of improvements may be made study we found two, one each in ppsspp and codelite, that to Add/Remove/Replace Categories. contained auto-generated files, these were ignored. With this we finish answering RQ2 and RQ3. That is, Only C++ is used as part of the study. Results may be changes in method stereotypes are statistically uncommon. somewhat different for other languages. Currently, StereoCode When they do change, many categories of changes are of little only supports C++ and is thus a limitation. concern. However, specific categories of changes in method One threat is that the amount of revisions contributed by stereotypes (To Unclassified, Cross Stereotype Boundaries, and each project is not uniform. That is, large systems such as Clang Add/Remove/Replace Categories) can indicate code smells, that (over 56K revisions) contribute much more than a much smaller is method design problems and inappropriate changes to code. project such as Tera (832 revisions), and the distribution of these may be different between them. Mitigating this, we normalized inline const Tds & tds() const the data per system and present those results. In addition, the { return _tds;} largest project (Clang), contributed less than 13% of the total number of revisions and thus no one system dominated the Fig. 1. Example of a benign change. Method stereotype changes from a non_const_get method (Structural Accessor) to a get method (Structural results. In addition, in a preliminary run of the experiment that Accessor). Developer simply added const to return type and method. differed by well over 100K revisions, the authors found very similar results. That is, even when different projects are === Method === investigated the results are very much the same. void BarrierOption::initialize() const { Lastly, manual investigation is subject to human error. sigmaSqrtT_ = volatility_ * QL_SQRT(residualTime_); Mitigating this, the process was done carefully, and detailed mu_ = (riskFreeRate_ - dividendYield_)/ notes taken. When the encoder was unsure about the change, (volatility_ * volatility_) - 0.5; another expert programmer was consulted. In addition, a muSigma_ = (1 + mu_) * sigmaSqrtT_; breadth instead of depth look at the changes in method dividendDiscount_ = QL_EXP(-dividendYield_*residualTime_); stereotypes is performed. One sample is certainly not riskFreeDiscount_ = QL_EXP(-riskFreeRate_*residualTime_); greeksCalculated_ = false; representative of every possible change that could induce that } particular change in stereotype. That is, we can only conclude === Data Members === that changes in method stereotype can indicate problems, private: however, we cannot give the extent to which they do. BarrierType barrType_; double barrier_, rebate_; mutable double sigmaSqrtT_, mu_, muSigma_; VIII. CONCLUSIONS mutable double dividendDiscount_, riskFreeDiscount_; The work presented examined how methods change in the Math::CumulativeNormalDistribution f_; face of evolution. Specifically, we examine how the stereotype Fig. 2. Example of a suspicious change. Method stereotype changes from of a method (an abstraction of a method’s role and behavior) command (Structural Mutator) to void-accessor (Structural Accessor). changes as the method is changed. The version histories of 50 Developer made an initialize method const and the data members it modifies mutable. open source systems were examined. Out of the approximately 1.4 million changes to methods, we found that the stereotype of a method rarely changed. About 90% of changes to methods VII. THREATS TO VALIDITY resulted in no change to its stereotype. Hence, we can conclude Only standard C++ extensions are used to locate C++ files. that a method does not often change in original intent and are Most of the projects use only these extensions, however, some quite stable in that regard during the lifetime of a system. The 6 use unusual extensions which possibly contained C++ code. For closed-source systems display similar characteristics. example, a C++ extension followed by .in, which possible However, this gives question to the remaining ~10% of denotes a file that is used to generate code as part of the build changes that do impact the stereotype. Further manual system, and .tpp, which can possible contain template code. examination of these cases show that certain categories of These are only noticed in a few of the repositories. For future method-stereotype changes can be indicators of poor method work, these files can be examined more closely and a design or of inappropriate changes to a method. A determination made as to whether they should be included as categorization of various stereotype transitions and their part of the data collected. potential to impact the design is also proposed and supported by The .h extension is treated as C++, however, it is used both evidence from the manual investigation. as a C and C++ header extension. Some of the projects included While method stereotypes are a powerful descriptor of both C and C++ code and use .h for both. As C++ is largely a method role/behavior they will need to be combined with other super-set of C (with a few exceptions), the parsing of C code as analysis techniques to uncover other code smells. Since a C++ code is a minor threat. method stereotype can be automatically and quickly computed, these results could be easily integrated into a development [16] N. Dragan, M. L. Collard, M. Hammad, and M. I. Maletic, “Using process to notify developers or project managers of potentially Stereotypes to Help Characterize Commits,” presented at the 27th IEEE International Conference on Software Maintenance (ICSM’11), 2011, pp. problematic changes to a method; potentially triggering code 520–523. reviews or other precautionary measures. [17] M. L. Collard, M. J. Decker, and J. I. Maletic, “Lightweight In this study, we investigate how individual methods evolve Transformation and Fact Extraction with the srcML Toolkit,” presented and not a project as a whole. As such, we did not investigate at the 11th IEEE Interational Conference on Source Code Analysis and benign cases (e.g., Add Collaborational) that can be suspicious Manipulation, 2011, pp. 173–184. in large numbers. For future work, we will look at how [18] L. Moreno, J. Aponte, G. Sridhara, A. Marcus, L. Pollock, and K. Vijay- collections of method stereotype changes can be used as Shanker, “Automatic Generation of Natural Language Summaries for Java Classes,” in 21st International Conference on Program indicators. Additionally, we would like to take this work further Comprehension (ICPC’13), 2013, pp. 23–32. to explore how we can use stereotype transitions in combination [19] Natalia Dragan, “The Emergent Laws of Method and Class Stereotypes with log and structural information to improve upon past in Object Oriented Software,” Ph.D. Dissertation, Kent State University, research using commit history to predict/analyze code health. Kent, Ohio USA, 2010. This work was supported in part by a grant from the US [20] M. Mantyla, J. Vanhanen, and C. Lassenius, “A Taxonomy and an Initial National Science Foundation CNS 13-05292/05217. Empirical Study of Bad Smells in Code,” in International Conference on Software Maintenance (ICSM’03), 2003, pp. 381–384. REFERENCES [21] A. Rani and J. K. Chhabra, “Evolution of Code Smells Over Multiple [1] B. W. Boehm, Software Engineering Economics, vol. 197. Prentice Hall Versions of Softwares: An Empirical Investigation,” in 2017 2nd PTR, 1981. International Conference for Convergence in Technology (I2CT), 2017, pp. 1093–1098. [2] M. Tufano et al., “When and Why Your Code Starts to Smell Bad,” in 2015 IEEE/ACM 37th IEEE International Conference on Software [22] M. Tufano et al., “When and Why Your Code Starts to Smell Bad (and Engineering, 2015, vol. 1, pp. 403–414. Whether the Smells Go Away),” IEEE Trans. Softw. Eng., vol. 43, no. 11, pp. 1063–1088, Nov. 2017. [3] M. Fowler and K. Beck, Refactoring: Improving the Design of Existing [23] F. Palomba, G. Bavota, M. Di Penta, R. Oliveto, A. De Lucia, and D. Code. Addison-Wesley Professional, 1999. Poshyvanyk, “Detecting Bad Smells in Source Code Using Change [4] R. Marinescu, “Detection Strategies: Metrics-based Rules for Detecting History Information,” in Proceedings of the 28th IEEE/ACM Design Flaws,” in 20th IEEE International Conference on Software International Conference on Automated Software Engineering, Maintenance, 2004. Proceedings., 2004, pp. 350–359. Piscataway, NJ, USA, 2013, pp. 268–278. [5] N. Moha, Y. G. Gueheneuc, L. Duchien, and A. F. L. Meur, “DECOR: A [24] N. Tsantalis, T. Chaikalis, and A. Chatzigeorgiou, “JDeodorant: Method for the Specification and Detection of Code and Design Smells,” Identification and Removal of Type-Checking Bad Smells,” in 2008 12th IEEE Trans. Softw. Eng., vol. 36, no. 1, pp. 20–36, Jan. 2010. European Conference on Software Maintenance and Reengineering, [6] F. A. Fontana, M. Zanoni, A. Marino, and M. V. Mäntylä, “Code Smell 2008, pp. 329–331. Detection: Towards a Machine Learning-Based Approach,” in 2013 IEEE [25] M. Fokaefs, N. Tsantalis, E. Stroulia, and A. Chatzigeorgiou, International Conference on Software Maintenance, 2013, pp. 396–399. “JDeodorant: Identification and Application of Extract Class [7] N. Dragan, M. L. Collard, and J. I. Maletic, “Reverse Engineering Method Refactorings,” in Proceedings of the 33rd International Conference on Stereotypes,” presented at the 22nd IEEE International Conference on Software Engineering, New York, NY, USA, 2011, pp. 1037–1039. Software Maintenance (ICSM’06), 2006, pp. 24–34. [26] M. Fokaefs, N. Tsantalis, and A. Chatzigeorgiou, “JDeodorant: [8] L. Moreno and A. Marcus, “JStereoCode: Automatically Identifying Identification and Removal of Feature Envy Bad Smells,” in 2007 IEEE Method and Class Stereotypes in Java code,” presented at the 27th International Conference on Software Maintenance, 2007, pp. 519–520. IEEE/ACM International Conference on Automated Software [27] D. Mazinanian, N. Tsantalis, R. Stein, and Z. Valenta, “JDeodorant: Engineering, Essen, Germany, 2012. Clone Refactoring,” in 2016 IEEE/ACM 38th International Conference [9] N. J. Abid, N. Dragan, M. L. Collard, and J. I. Maletic, “Using Stereotypes on Software Engineering Companion (ICSE-C), 2016, pp. 613–616. in the Automatic Generation of Natural Language Summaries for C++ [28] D. Sahin, M. Kessentini, S. Bechikh, and K. Deb, “Code-Smell Detection Methods,” presented at the IEEE International Conference on Software As a Bilevel Problem,” ACM Trans Softw Eng Methodol, vol. 24, no. 1, Maintenance and Evolution (ICSME’15), 2015, pp. 561–565. pp. 6:1–6:44, Oct. 2014. [10] P. Andras, A. Pakhira, L. Moreno, and A. Marcus, “A Measure to Assess [29] U. Mansoor, M. Kessentini, B. R. Maxim, and K. Deb, “Multi-Objective the Behavior of Method Stereotypes in Object-Oriented Software,” in Code-Smells Detection Using Good and Bad Design Examples,” Softw. 2013 4th International Workshop on Emerging Trends in Software Qual. J., vol. 25, no. 2, pp. 529–552, Jun. 2017. Metrics (WETSoM), 2013, pp. 7–13. [30] A. Hindle, D. M. German, M. W. Godfrey, and R. C. Holt, “Automatic [11] N. Alhindawi, J. I. Maletic, N. Dragan, and M. L. Collard, “Improving Classication of Large Changes into Maintenance Categories,” in 2009 Feature Location by Enhancing Source Code with Stereotypes,” presented IEEE 17th International Conference on Program Comprehension, 2009, at the 29th IEEE International Conference on Software Maintenance pp. 30–39. (ICSM’13), 2013, pp. 1–10. [31] L. P. Hattori and M. Lanza, “On the Nature of Commits,” in Proceedings [12] G. Canfora and L. Cerulo, “Impact Analysis by Mining Software and of the 23rd IEEE/ACM International Conference on Automated Software Change Request Repositories,” presented at the 11th IEEE International Engineering, Piscataway, NJ, USA, 2008, pp. III–63–III–71. Symposium on Software Metrics (METRICS’05), 2005, pp. 29–37. [32] J. J. Amor, G. Robles, J. M. Gonzalez-Barahona, and A. Navarro, [13] C. D. Newman, R. S. AlSuhaibani, M. L. Collard, and J. I. Maletic, “Discriminating Development Activities in Versioning Systems: A Case “Lexical Categories for Source Code Identifiers,” in 2017 IEEE 24th Study,” in Proceedings PROMISE, 2006, vol. 2006, p. 2nd. International Conference on Software Analysis, Evolution and Reengineering (SANER), 2017, pp. 228–239. [33] A. Hindle, M. W. Godfrey, and R. C. Holt, “What’s Hot and What’s Not: Windowed Developer Topic Analysis,” in 2009 IEEE International [14] M. Linares-Vásquez, L. F. Cortés-Coy, J. Aponte, and D. Poshyvanyk, Conference on Software Maintenance, 2009, pp. 339–348. “ChangeScribe: A Tool for Automatically Generating Commit Messages,” in 2015 IEEE/ACM 37th IEEE International Conference on [34] Michael John Decker, “srcDiff: Syntactic Differencing to Support Software Maintenance and Evolution,” Dissertation, Kent State Software Engineering, 2015, vol. 2, pp. 709–712. University, 2017. [15] N. Dragan, M. L. Collard, and J. I. Maletic, “Automatic Identification of Class Stereotypes,” presented at the IEEE International Conference on Software Maintenance (ICSM’10), 2010, pp. 1–10.