Software clones in scratch projects: on the presence of copy-and-paste in computational thinking learning

Robles, Gregório; Moreno-León, Jesús; Aivaloglou, Efthimia; Hermans, Felienne

doi:10.1109/iwsc.2017.7880506

Cited by 38 publications

(27 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Furthermore, a detailed study into the readability of variable names with and without spaces, and procedures with and without labels would help us to create naming guidelines for Scratch. Finally, one additional area to explore is the relation between name length of variables with the level of computational thinking [51], [52] of the Scratch programmer in addition to other demographic factors like gender, age and language.…”

Section: Discussionmentioning

confidence: 99%

How do Scratch Programmers Name Variables and Procedures?

Swidan

Serebrenik

Hermans

2017

2017 IEEE 17th International Working Conference on Source Code Analysis and Manipulation (SCAM)

Self Cite

View full text Add to dashboard Cite

Research shows the importance of selecting good names to identifiers in software code: more meaningful names improve readability. In particular, several guidelines encourage long and descriptive variable names. A recent study analyzed the use of variable names in five programming languages, focusing on single-letter variable names, because of the apparent contradiction between their frequent use and the fact that these variables violate the aforementioned guidelines. In this paper, we analyze variables in Scratch, a popular blockbased language aimed at children. We start by replicating the above single-letter study for Scratch. We augment this study by analyzing single-letter procedure names, and by investigating the use of Scratch specific naming patterns: spaces in variable names, numerics as variables and textual labels in procedure names. The results of our analysis show that Scratch programmers often prefer longer identifier names than developers in other languages, while Scratch procedure names have even longer names than Scratch variables. For the single-letter variables, the most frequent names are x, y, and i. Single-letter procedures are less popular, but show more tendency to be in upper case. When compared to the other programming languages, the usage of single uppercase letters in Scratch variables seems to be similar to the pattern found in Perl, while for the lowercase letters-to the pattern found in Java. Concerning Scratch specific features, 44% of the unique variable names and 34% of the projects in the dataset include at least one space. The usage of textual labels between parameters in procedure names appears as not common, however textual patterns used imply an influence from textual languages, for example by using brackets. Previous research indicate the identifier names as one significant issue in transitioning from visual block-based to textual programming languages. The naming patterns we found support this claim for Scratch programmers who may incur difficulties when transitioning to the use of mainstream textual programming languages. Those languages restrict the use of spaces in identifiers and more often divert into short and single-letter namestendencies opposite to the naming preferences in Scratch.

show abstract

Section: Discussionmentioning

confidence: 99%

How do Scratch Programmers Name Variables and Procedures?

Swidan

Serebrenik

Hermans

2017

2017 IEEE 17th International Working Conference on Source Code Analysis and Manipulation (SCAM)

Self Cite

View full text Add to dashboard Cite

show abstract

“…Despite all the aforementioned efforts made in these research lines, there is almost no research concerning the prevention of code cloning. This is because both developers and researchers believe that code cloning is inevitable as a direct consequence of human developer faults . This is a consequence of copy‐paste (because it is easier than generating code manually), in addition to the ignorance regarding the existence of similar source code pieces in huge unmanageable information systems that could be reused.…”

Section: Related Workmentioning

confidence: 99%

“…This is because both developers and researchers believe that code cloning is inevitable as a direct consequence of human developer faults. 34 This is a consequence of copy-paste (because it is easier than generating code manually), in addition to the ignorance regarding the existence of similar source code pieces in huge unmanageable information systems that could be reused. In order to prevent or limit code cloning, the first step should be to determine factors that affect code cloning in a development project.…”

Section: Clone Prediction and Preventionmentioning

confidence: 99%

An empirical study on how project context impacts on code cloning

Pérez‐Castillo

Piattini

2018

J Software Evolu Process

View full text Add to dashboard Cite

Code cloning can seriously affect software quality. Code clones are various fragments of syntactically or semantically equivalent code. Some authors argue that code clones have a negative impact on maintainability and understandability, since clones propagate defects and make it mandatory to pay attention to several copies. However, other authors believe clones are not necessarily bad, since self‐admitted clones favor system stability and allow developers to move projects forward. Although some root causes and effects of cloning have been widely studied, there is not much relevant work analyzing how certain projects context factors impact on code cloning. This work presents an empirical validation of six open source projects by considering certain factors from Git repositories measured throughout a total of 70 releases for the 6 systems. The factors analyzed were the number of commits and committers per release, the average size of the commits and the size of the system in each release. The main conclusion obtained from the study is that, while the number of commits and committers and the system size do not significantly affect cloning, larger commits lead to a higher cloning ratio. These insights contribute to predicting and preventing code cloning, thus enabling a software quality improvement.

show abstract

“…The Dr. Scratch computational thinking (CT) assessment uses custom blocks and cloning to measure abstraction in Scratch projects. However, research has shown that these are not often used in projects, and when they are, they do not impact the amount of duplication in projects (Robles et al, 2017). Using custom blocks and clones requires good abstraction skills, which primary school children should be able to learn if the content is presented in a structured way (Gibson, 2012).…”

Section: Benefits Of Abstraction In Scratch?mentioning

confidence: 99%

“…This makes projects easier to understand, debug and maintain. Yet, even when they are used, Scratch users still frequently copy and paste code (Robles et al, 2017), indicating that they are not used correctly. This may be because code reuse and refactoring require abstract reasoning skills, which are only developed as the programmer gains expertise.…”

Section: Custom Blocks and Cloningmentioning

confidence: 99%

Developing Children’s Computational Thinking using Programming Games

Rose¹

View full text Add to dashboard Cite

Computation is a fundamental part of our world, with today's children growing up surrounded by technology. This has led governments and policymakers to introduce computer science into primary and secondary education (age 5 to 16). These developments have been driven by 'computational thinking': the idea that the problemsolving skills used in computer science are useful in other disciplines. They have resulted in a wide range of programming tools designed for novices, of which Scratch, a block-based visual programming environment, is the most popular. Yet, so far, both computer science education and claims of computational thinking as a universal skill have failed to live up to their potential. This thesis begins by reviewing the literature on computer science in primary education and computational thinking. It then describes a study that aimed to reproduce findings that programming improves story sequencing, a non-computational skill, in young children (age 5 and 6) using a programming game. The results showed an overall improvement for both the intervention and control group. In addition, it highlighted issues with teaching programming to young children. The thesis then refocuses on teaching older children (age 9 to 11) the computer science skill of abstraction and the idea that it can be used to refactor code to remove 'code smells' (bad programming practices). Code smells indicate an underlying problem in a program, such as code duplication, and are common in Scratch projects. A study is then reported that establishes that primary school children can recognise the benefits of abstraction when asked to alter Scratch projects that contain it. The thesis then describes the design and development of Pirate Plunder, a novel educational block-based programming game designed to teach children to use abstraction in Scratch, using custom blocks (parameterised procedures) and cloning (instances of sprites). Two studies are reported in the subsequent chapters. The first investigates the value of a debugging-first approach in Pirate Plunder, finding that it was not always beneficial. The second measures for improvements in using abstraction in Scratch, finding that children who played the game were then able to use custom blocks to reduce duplication code smells in a Scratch project. In addition, Pirate Plunder players improved on a computational thinking assessment compared to the non-programming control group. The final chapter discusses the original contributions of the thesis, the implications of these and future direction. Declaration I hereby declare that: 1. I have not been enrolled for another award of the University, or other academic or professional organisation, whilst undertaking my research degree. 2. None of the material contained in the thesis has been used in any other submission for an academic award. 3. I am aware of and understand the University's policy on plagiarism and certify that this thesis is my own work. The use of all published or other sources of material consulted have been properly and fully...

show abstract

Software clones in scratch projects: on the presence of copy-and-paste in computational thinking learning

Cited by 38 publications

References 16 publications

How do Scratch Programmers Name Variables and Procedures?

How do Scratch Programmers Name Variables and Procedures?

An empirical study on how project context impacts on code cloning

Developing Children’s Computational Thinking using Programming Games

Contact Info

Product

Resources

About