WIXLIB

changing function signatures (i.e., add parameters and changetheir order). These built-in refactorings can be implemented byfollowing a simple match-and-replace program transformationstrategy, insufficient to support our advanced refactorings.Several prior works analyze code quality [6], [4] and createanalysis tools (i.e., Hairball [18], Dr.Scratch [19], and QualityHound [20]). However, these prior works neither focus on howto address quality problems nor on how to apply automatedtools. By identifying recurring Scratch code smells, these priorworks inspire the refactorings described herein.We designed our refactoring user interface to favor simplicity over versatility, in line with our target audience. That is, aquality hint is presented as a light bulb, on which the programmer can mouse over to see the suggested code improvementcontext, and then right-click to apply the suggested refactoring.We chose this simple design over more complex interfaces,such as those that embrace the native drag-and-drop idioms ofblock-based programming. Even though these idioms inspireda novel refactoring user interface for Java [21], they would bepoorly suited for refactoring block-based code, as they requirea detailed knowledge of the source and target destinationsof the intended refactoring transformations. Hence, drag-anddrop refactoring interfaces are better suited for object hierarchies, with clearly delineated boundaries between programconstructs. Our user study answers the fundamental questionof whether access to automated refactoring support motivatesnovice programmers and end-users to improve code quality inthis domain.repeat2changeghostA. Extract Custom BlockThis refactoring creates a procedure, whose body comprisesthe repeated code fragment being refactored, and replaces alloccurrences of this fragment with the appropriately parameterized invocations of the created procedure.Precondition: For behavioral preserving transformation,each argument to be parameterized must be a constant andcan be parameterized. Note that some blocks accept a dropdown option value and cannot be parameterized. Finally,the extracted fragment must not contain the control flowterminating command (i.e., “stop this script ” block).B. Extract Parent SpriteThis refactoring removes duplicate sprites by extractingthe parent sprite which instantiates its children clones using “create clone of target ” block1 . Encapsulatedwithin a sprite, the same code is not only easier to modify, butis also amenable to other localized refactorings (e.g., E XTRACTC USTOM B LOCK, E XTRACT C ONSTANT, etc.). Automated refactoringcannot remove sprite duplicates in all cases. Some of the1 ��ect byspeedchange2-5010-10.ghosteffect bystepfade-10.Fig. 1. E XTRACT C USTOM B LOCKremovals require adding boilerplate code, which would behard to generate automatically and require advanced programming expertise to understand. Hence, the refactoring presentedherein is applicable when sprite duplicates share similar code(usually at the beginning when a duplicate has just been introduced). Note that the “hide” block is immediately executedin the parent sprite, so as to emulate an invisible prototypeobject, whose only purpose is to clone visible children.Preconditions: Sprite duplicates have identical set of scripts(exact code duplication, without variation in literals and identifiers (e.g. variable references)). Each sprite duplicate containsno scripts starting with the “when I start as a clone”block. Finally, this Each sprite duplicate uses a single costume.sprite: Star1whenstar1sprite: Starclickedgo toIII. R EFACTORING C ATALOGNext we present our refactoring catalog. For each refactoring, we list its rationale and preconditions. Due to spacelimitation, we only illustrate the affected program parts beforeand after the application of complex refactorings.effect byrandom position41when I start as a rite: Star2star2whengo toclickedrandom positionforever3switch to costumecreate clone ofcreate clone ofstar1myselfswitch to costumeflickersshowstar2when I start as a clonego torandom positionforeverflickersmyselfFig. 2. E XTRACT PARENT S PRITEC. Extract ConstantThis refactoring replaces replicated constant values with avariable. Descriptively named variables improve comprehension and modifiability [22]. The only precondition is that thereplicated values must be of type literal.D. Reduce Variable ScopeThis refactoring changes the scope of an existing variablefrom being accessible to all sprites to only a given sprite. Ifglobal scope for a variable is not needed, reducing its scopeimproves the sprite’s data encapsulation.Preconditions: Only one sprite modifies the rescoped variable (though it can be read by multiple sprites)

IV. R EFACTORING FOR S CRATCHAlthough we introduce automated refactoring to Scratch,our general architecture and design can be applied to anyblock-based programming environment.Overall Architecture: Exposed as remote services, therequired program analysis and transformation functionalitiesintegrate non-intrusively. Passed a serialized form of the editedprogram as input, these services analyze and detect codesmells, returning the computed refactoring transformations.Implementation: Based on its input parameters, the refactoring engine analyzes and transforms the edited program. Therefactoring parameters can be specified by the programmeror in our case automatically extracted from the smells (e.g.,D UPLICATE C ODE E XTRACT C USTOM B LOCK request). Beforeperforming any transformations, the refactoring engine determines whether a given refactoring request satisfies all ofits preconditions. In the transformation phase, the refactoringengine modifies the analysis AST, while recording each modification as a transformation action. Having been transferredback to the client-side, this atomic sequence of actions isapplied to the program model, maintained by the block-basedprogramming environment. The actions are applied in thespecified order, as each of them modifies program state.Fig.3 shows some transformation action types used toimplement E XTRACT C ONSTANT. Each action is persisted, so theclient can replay the corresponding transformations on theclient-side’s program model. Our design assumes all programelements (both blocks and non-blocks) can be looked up basedon their string IDs, so program changes can be mapped acrossrepresentations. Additionally, the blocks editor can serializeand deserialize its internal program model (e.g., in XML orJSON data format).Our program analysis and transformation operate on an ASTby means of JastAdd [14], a language processing framework2AssignStmtVarDecl criptbody3BlockSeqSpriteExprStmt5ExprStmt1.) build AST2.) check preconds.3.) compute transformsExtract Constant Request:Param: List Literal // all "167"VarName: "xpos"Var 4AccessSeq. of ActionsVarDeclarAction1 name: xposid: var1 id2 BlockCreateActionxml: block type: setvar .BlockInsertAction3 target: loopstmt idwith: setvar id4 BlockCreateActionxml: block type: data-var.5 BlockReplaceActiontarget: num literal idwith: var1 id.applytransformationspreviously mentioned in II. We express various relationshipsbetween program elements in a program graph with its declarative specification language to augment the AST classes.Fig.3 illustrates the major phases of refactoring with anexample of performing E XTRACT C ONSTANT. The first phasestarts with a refactoring request, whose parameters for E XTRACTC ONSTANT comprise all the block’s IDs of all duplicate literalsand the edited program. To determine if all preconditionsare met, the server-side refactoring engine executes variousanalysis routines (e.g., check preconds) on the parsed AST.Then, the engine computes and record a sequence of transformations (i.e., “Actions”) that put the refactoring into effect(“compute transforms”). The resulting transformation actionsare serialized and returned to the blocks editor, which presentsthe discovered smell hints along with the suggested refactoringtransformations (“apply transformations”).Refactoring Interface Design: While experienced programmers eagerly refactor their code, novice programmers areunfamiliar with the practice. Hence, the latter’s willingness torefactor needs to be encouraged with a friendly and intuitiveuser interface. Refactoring starts from identifying code whosequality can be improved, a hard task that is even harderfor novice programmers. To render refactoring accessible toour target audience, we follow two key design principles,also demonstrated in the screenshot in Fig.4, an example ofapplying E XTRACT C USTOM B LOCK refactoring to a real-worldScratch project.1) Code smells should be presented as improvement opportunities to the programmer. Fig.4A displays a codehint as a light-bulb icon, indicating an opportunity forimproving code quality (E XTRACT C USTOM B LOCK in thiscase). Whenever possible a hint should be visually contextualized. For E XTRACT C USTOM B LOCK refactoring, ourrefactoring interface highlights duplicate code blocks.2) Refactoring should be immediately actionable. Insteadof relying on the programmer to specify the requiredrefactoring parameters, as in traditional refactoring, theinfrastructure should present only the actions ready forthe programmer to act upon. Fig.4B shows “Help mecreate the custom block”, the only available action forthis hint in a simple terminology that can be easilyunderstood by novice and end-user programmers.Note that in this example, an additional refactoring hint,shown after the application of E XTRACT C USTOM B LOCK, suggeststo the programmer that the just-extracted custom block shouldbe meaningfully renamed.V. E VALUATIONAutomated refactoring can become helpful for novice andend-user programmers in improving the quality of theirprojects, as long as the refactorings are applicable, useful,and accessible for this programming audience. Our evaluationseeks answers to the following questions:RQ1. How applicable is each introduced refactoring?RQ2. How do the refactorings impact code quality?Fig. 3. Different stages of E XTRACT C ONSTANT refactoring

ACBFig. 4. A screenshot of the E XTRACT C USTOM B LOCK refactoring invocation interface for ScratchRQ3. Do refactoring tools motivate quality improvement?To answer RQ1 and RQ2, we experimentally evaluate arepresentative sample of Scratch projects. We refactor the codesmells, automatically detected by our infrastructure’s smellanalysis modules. To answer RQ3, we conduct an onlinebetween-subjects study, in which participants in the treatmentgroup interact with our refactoring infrastructure and answersurvey questions.A. Experimental EvaluationWe limit the scope of our evaluation to highly prevalentsmells and whether our refactorings can remove them. Notethat some refactorings can remove more than one type ofcode smell (e.g., E XTRACT C USTOM B LOCK can remove bothL ONG S CRIPT [4] and D UPLICATE C ODE smells). Hence, if wewere to apply the available refactorings to remove all automatically detected smells, such an evaluation strategy woulddistort the applicability results and the refactored code quality, as some of the detected smells may not be indicative of actual quality problems (e.g.,what constitutes a L ONGS CRIPT is highly subjective). To avoid such distortions, ourevaluation considers the following fixed SMELL REFACTORINGpairs: D UPLICATE C ODE E XTRACT C USTOM B LOCK, D UPLICATES PRITE E XTRACT PARENT S PRITE, D UPLICATE C ONSTANT E XTRACTC ONSTANT, and B ROAD S COPE VARIABLE R EDUCE VARIABLE S COPE.Evaluation Dataset: To assess how viable the refactoringsare, we measure the applicability and impact of applying themto third-party Scratch programs. An API request2 to MIT’sScratch service retrieves a list of projects, divided into twocategories of approximately equal size: (1) trending and (2)recent. This subject selection strategy ensures that we conductour evaluation on a diverse sample of projects created bythe Scratch community. We collected a total of 448 projects51% among them were viewed at most once, with the restof projects were viewed on average 12,749 times. Among thesubject projects, 88% were remixed at most once and the restwere remixed on average 93 times.2 https://scratch.mit.edu/explore/projects/all/ recent trending Code Broad ScopeVariableDefinition and Detection Criteria2 or more code fragments, containing more than one statement,are duplicate if they have identical structure except for variations in identifiers and literals (type II in clone classification[23]). If multiple duplicate fragments overlap, the largest isselected.2 or more sprites are duplicate if each script within one of thesprites is duplicated in the others.Exact literals of at least 3 characters that are replicated at leasttwice (the thresholds identified experimentally to reduce falsepositive results)A variable declared in the global scope (Stage), but assignedonly locally in a single spriteTABLE IC ODE S MELL D EFINITIONSRQ1. Refactoring Applicability: For each refactoring,we assess its applicability by calculating the percent of itsassociated smells that are refactorable. Because code smelldefinitions affect the applicability of refactorings, Table I liststhe considered smells and their detection criteria as the basesfor interpreting our evaluation results.AfflictedTotal RefactoredProjects SmellsSmellsDuplicate Code Extract Custom Block 181 (41%) 290229 (79%)Duplicate Sprite Extract Parent Sprite 142 (32%) 19322 (11%)Duplicate Constant Extract Constant194 (43%) 453 453 (100%)Broad Scope Var. Reduce Var. Scope94 (21%)145118 (81%)Smell RefactoringTABLE IIA PPLICABILITY (N 448)Results: Table II summarizes the results of evaluatingrefactoring applicability. In our evaluation, as long as a projectcontains at least one instance of a given code smell, the projectis considered afflicted by that smell. Different smells have beenfound to afflict different projects in the evaluation dataset.Afflicting over 30% of the subject projects, duplicationrelated smells are the most prevalent; afflicting around 21%,B ROAD S COPE VARIABLE is the least prevalent smell. One projectmay contain more than one instance of the same code smell(Total.Smells No.Afflicted.Projects). We use all detectedsmells to evaluate refactoring applicability.

MetricDefinitionLOC# statement blocks within a programComplex Script Dens. % of scripts (including procedure) with McCabe’s cyclomatic complexity [24] value 10(risk threshold according to [25])Long Script Dens.% of scripts (including procedure) with LOC 11 LOC (threshold empirically determined inprevious work [4])Procedure Dens.# procedures within a program per 100 LOCsNo. Literals# literals (numbers and strings) within a programNo. Global Var.# global variablesNo. Create Clone Of. # C REATE C LONE O F TARGET blocksTABLE IIIM ETRICS D EFINITIONSThe applicability of the introduced refactorings varieswidely. With the success rate of over 75%, E XTRACT C ONSTANT,R EDUCE VARIABLE S COPE, and E XTRACT C USTOM B LOCK are themost applicable refactorings. E XTRACT C USTOM B LOCK’s precondition failures are due to the variations in duplicate fragmentsfailing to satisfy the preconditions (60% of the variationscontain global variables and 31% contain non-constant expression blocks; 9% are located at non-parameterizable inputslots). As expected, E XTRACT PARENT S PRITE is the least applicable refactoring due to its restrictive preconditions—only11% of the detected smell instances can be refactored. Thereason for failures is that E XTRACT PARENT S PRITE cannot handlecertain duplicate sprites, out of which 63% differ slightly interms of their contained code, 33% are multi-costumes, and4% contain scripts starting with the “when I start as aclone” block. Overall, we observe the introduced refactoringsto be satisfactorily applicable to the highly recurring smelltypes. Even the least applicable refactoring—E XTRACT PARENTS PRITE—can be applied frequently enough.RQ2. Refactoring Impact on Quality: To assess howeach refactoring impacts program quality, we apply all theevaluated refactorings in sequence on each of the detectedsmell type instances. We then compute the relevant softwaremetrics of the original and the refactored versions of eachsubject program, so as to determine the difference or the deltain code quality, which serves as a measure of refactoringquality impact. Table III defines the software metrics used.Results: Table IV summarizes the characteristics of thedetected smells that are refactorable. Table V summarizes thepercentage changes for different software metrics before andafter performing each refactoring. To help the reader interpretthe results, the last column translates the mean deltas intopercent improvements. Group Size refers to the number ofreplications of a given program element. Next, we describethe results in terms of different code quality attributes. TotalUses refers to the number of times a given variable is read ina project. External Uses refers to the number of times a givenvariable is read from outside the sprite in which it is defined.Size: We expect duplication-eliminating refactorings toremove redundant code and decrease the code size of theafflicted projects. We observe that E XTRACT C USTOM B LOCKreduces a varying level of code size. A small improvementin code size is due to the small number of repetitions detectedmore frequently than bigger ones. Thus, most projects see aMetricsDuplicate CodeGroup SizeFragment SizeDuplicate SpriteGroup SizeSprite Size (LOC)Duplicate ConstantGroup SizeLiteral LengthBroad Scope VariableTotal UsesExternal 63.1410311358118900010102.730.472.000.75606TABLE IVC HARACTERISTICS OF R EFACTORABLE S MELLSmean decrease in LOC by 3.38%. Though less applicable,E XTRACT PARENT S PRITE refactoring removes large duplicationsat the sprite level. A subset of projects afflicted by D UPLICATES PRITE see a greater mean decrease in LOC by 8.49%.Comprehension: We expect E XTRACT C USTOM B LOCK tohelp shorten some long scripts and reduce the number ofcomplex scripts due to the original script being extracted. Weobserve 4.4% decrease in the number o

supporting Scratch programmers in improving the code quality of their projects can increase the pedagogical and productivity benefits of this programming domain. To address this problem, we added automated refactoring support to Scratch 3.0, validated by implementing four refac-tori