Java remains one of the most popular programming languages in education. Although Java programming education is well supported by study materials, learners also need more immediate support on the problems they face in their own code. When this support cannot be offered by educators personally, learners can resort to automated program analysis tools such as linters, which provide feedback on potential bugs or code issues. This is constructive feedback, but it may nevertheless feel like criticism. This paper introduces code perfumes for Java, a simple program analysis technique similar to linting, but commending the correct application of good programming practices. We present a catalogue of 20 Java code perfumes related to common Java language constructs for beginner to immediate learners. Our evaluation shows that these code perfumes occur frequently in learners' code, and programs with more code perfume instances tend to have better functionality and readability. Moreover, students who incorporate more code perfumes tend to achieve higher grades. Thus, code perfumes serve as a valuable tool to acknowledge learners' successes, and as a means to inform instructors about their learners' progress.

Block-based programming languages like Scratch are increasingly popular for programming education and end-user programming. Recent program analyses build on the insight that source code can be modelled using techniques from natural language processing. Many of the regularities of source code that support this approach are due to the syntactic overhead imposed by textual programming languages. This syntactic overhead, however, is precisely what block-based languages remove in order to simplify programming. Consequently, it is unclear how well this modelling approach performs on block-based programming languages. In this paper, we investigate the applicability of language models for the popular block-based programming language Scratch. We model Scratch programs using n-gram models, the most essential type of language model, and transformers, a popular deep learning model. Evaluation on the example tasks of code completion and bug finding confirm that blocks inhibit predictability, but the use of language models is nevertheless feasible. Our findings serve as foundation for improving tooling and analyses for block-based languages.

Block-based programming languages like Scratch are commonly used to introduce young learners to programming. While coding, learners may encounter problems, which may require teachers to intervene. However, teachers may be overwhelmed with help requests in a classroom setting, and in independent learning scenarios, teachers may not be available at all. Automated tutoring systems aim to help by providing hints, but misleading or confusing hints can be detrimental. To better understand the effects of automatically generated hints, in this paper we study a state-of-the-art hint generation system that provides suggestions when learners fail to complete a step in a programming tutorial. The system is evaluated using two cohorts of students aged 12-13, where one cohort receives only textual hints based on test failures while the other additionally receives visual next-step support in terms of illustrated code changes. We find that initially the automatically generated visual next-step hints increase the speed at which learners complete the steps of the tutorial and reduce the number of questions posed to teachers, without affecting the learners' overall understanding of their program negatively. However, with increasing complexity of the programs the quality of the hints degrades, thus calling for further research on improving hint generation systems.

Taking the first steps when learning how to program can be hard. Block-based programming languages like Scratch lower this hurdle, but learners may nevertheless get stuck when trying to solve a specific task and need help. This can also challenge teachers when facing many raised hands at the same time in the classroom. Consequently, it is desirable for learners and teachers alike to have access to systems that automatically generate hints on which steps to take next in a programming assignment. In this paper we introduce Catnip, a tool that generates next step hints for the Scratch programming language based on a structural comparison between model solutions and the current student attempt. Catnip uses extensive postprocessing to improve the generated hints, and displays them directly inside the Scratch framework, suggesting where to add or reorder blocks while working on a programming task.

Learning basic programming with Scratch can be hard for novices and tutors alike: Students may not know how to advance when solving a task, teachers may face classrooms with many raised hands at a time, and the problem is exacerbated when novices are on their own in online or virtual lessons. It is therefore desirable to generate next-step hints automatically to provide individual feedback for students who are stuck, but current approaches rely on the availability of multiple hand-crafted or hand-selected sample solutions from which to draw valid hints, and have not been adapted for Scratch. Automated testing provides an opportunity to automatically select suitable candidate solutions for hint generation, even from a pool of student solutions using different solution approaches and varying in quality. In this paper we present Catnip, the first nextstep hint generation approach for Scratch, which extends existing data-driven hint generation approaches with automated testing. Evaluation of Catnip on a dataset of student Scratch programs demonstrates that the generated hints point towards functional improvements, and the use of automated tests allows the hints to be better individualized for the chosen solution path.

Bugs in SCRATCH programs can spoil the fun and inhibit learning success. Many common bugs are the result of recurring patterns of bad code. In this paper we present a collection of common code patterns that typically hint at bugs in SCRATCH programs, and the LitterBox tool which can automatically detect them. We empirically evaluate how frequently these patterns occur, and how severe their consequences usually are. While fixing bugs inevitably is part of learning, the possibility to identify the bugs automatically provides the potential to support learners.