Teaching the software engineers of the future to write high-quality code with good style and structure is important. This systematic literature review identifies existing instructional approaches, their objectives, and the strategies used for measuring their effectiveness. Building on an existing mapping study of code quality in education, we identified 53 papers on code structure instruction. We classified these studies into three categories: (1) studies focused on developing or evaluating automated tools and their usage (e.g., code analyzers, tutors, and refactoring tools), (2) studies discussing other instructional materials, such as learning resources (e.g., refactoring lessons and activities), rubrics, and catalogs of violations, and (3) studies discussing how to integrate code structure into the curriculum through a holistic approach to course design to support code quality. While most approaches use analyzers that point students to problems in their code, incorporating these tools into classrooms is not straightforward. Combined with further research on code structure instruction in the classroom, we call for more studies on effectiveness. Over 40% of instructional studies had no evaluation. Many studies show promise for their interventions by demonstrating improvement in student performance (e.g., reduced violations in student code when using the intervention compared with code that was written without access to the intervention). These interventions warrant further investigation on learning, to see how students apply their knowledge after the instructional supports are removed.

The challenge of student retention in introductory-level computing classes is a key contributor to the lack of diversity in computing fields. While teaching assistants (TAs) play a critical role in these classes, their role in supporting student retention is yet to be explored. We employed a special TA, a retention TA (RTA), who focuses exclusively on supporting students who are at risk of failing the course. RTAs target students who are retaking the class or underperforming in exams or assignments. This contrasts with regular TAs, who focus on grading and other standard duties. In Spring 2024, four RTAs were assigned to four different introductory-level computing CS1 and CS2 classes. At the end of the semester, we analyzed student attendance records and compared the performance of students who sought help from RTAs to the overall class performance. In two of the four classes, students who engaged with RTAs performed better than the class average. We share experiences from one of those classes, including specific RTA strategies that may have contributed to student success, such as personalized communication, reviewing course content, and helping students get started on assignments.

Design empathy is a core HCI concept for understanding user perspectives in design processes. Although researchers advocate for leveraging design empathy in the design of assistive technology, educating novice designers about this is challenging; this is especially true in HCI classrooms when the target population includes people with disabilities, and students who do not have a disability are less aware of the diversity of disability. To help students better understand disability experiences, HCI education often adopts “be-like” (mimicking disabled-experience) approaches. However, accessibility researchers advocate adopting the “be-with” approach—learning about other’s experiences through companionship. To mitigate the logistical challenges of being-with in a classroom setting, we developed a “be-connected” approach, which facilitates learning about the disability experience through the narratives of real individuals. Using social media posts from a spinal cord injury subreddit, we developed and deployed an activity aiming to develop design empathy. Our qualitative evaluation showed a notable transformation in students’ design thinking process, suggesting an opportunity to leverage social media data to learn about disabled perspectives and develop design empathy.

How does students' knowledge of code structure improve as they progress through their degree, and where do students struggle? We conducted a comparative study between introductory (CS1) and intermediate CS students (CS2) to explore these questions. Using an online survey with several tasks, including identification of expert patterns, judgment of readable structure, code comprehension, code writing, and editing, we focused on two important code structures: (S1) returning boolean expressions directly and (S2) unique vs. repeated code within if and else. Student performance varied based on structure and task: in both S1 and S2, CS2 students demonstrated higher performance in identifying patterns, judgment of readable structure, and editing. However, evidence of improvement in code writing was only found for S1, and improvement in code comprehension was only found for S2. Therefore, students may need different supports across different code structures. With the exception of comprehension of S1, student performance was far below ceiling, suggesting a need for more support.

While the CS education community has successfully incorporated tech-ethics assignments and modules into computing courses, we lack a defined process for instructional design to create these materials from scratch across the curriculum. To enable the development of such a process, we explore two research questions: (1) What specific instructional design challenges emerge when creating ethically-integrated assignments for CS courses? And (2) what strategies might overcome them? We address these questions using Research through Design, a method for critically examining design processes. Applying this method to our own process of creating ethics-integrated CS assignments yielded four key challenges: identifying an ethical context, maintaining a technical focus, eliciting both ethical and technical thinking from students, and making the assignment practical for the classroom. Further, the Research through Design approach revealed process-level insights for addressing these challenges, which can apply across the computing curriculum. This paper also serves as a case study of Research through Design for CS education, highlighting the importance of the instructional design process and the behind-the-scenes challenges and design decisions that go into tech-ethics materials.

How can we teach students to use more readable code structures? How common is it for students to choose less readable (but still functional) alternatives? We explore these questions for a specific anti-pattern: using sequential if statements when conditions are exclusive (rather than using else-if or else). We created and validated an automated detector to identify this anti-pattern in student's code. Running the detector on 1,764 homework submissions (from 270 students in a CS2 class on data structures and algorithms) showed that this anti-pattern was common and varied by assignment: across 12 assignments, 3% to 50% of submissions used sequential ifs for exclusive cases. However, using this anti-pattern did not preclude using else-ifs: across assignments, up to 34% of the submissions used both forms. Further, students used sequential if statements in surprising ways, such as checking a condition and then the negation of that condition, indicating a more novice level of understanding than expected for an intermediate course. Hand-inspection of the detector-flagged cases suggests that sequential ifs for exclusive cases may be a code smell that can indicate larger problems with logic and abstraction.

How can we teach AI students to use human concerns to guide their technical decisions? We created an AI assignment with a human context, asking students to find the safest path rather than the shortest path. This integrated assignment evaluated 120 students’ understanding of the limitations and assumptions of standard graph search algorithms, and required students to consider human impacts to propose appropriate modifications. Since the assignment focused on algorithm selection and modification, it provided the instructor with a different perspective on student understanding (compared with questions on algorithm execution). Specifically, many students: tried to solve a bottleneck problem with algorithms designed for accumulation problems, did not distinguish between calculations that could be done during the incremental construction of a path versus ones that required knowledge of the full path, and, when proposing modifications to a standard algorithm, did not present the full technical details necessary to implement their ideas. We created rubrics to analyze students’ responses. Our rubrics cover three dimensions: technical AI knowledge, consideration of human factors, and the integration of technical decisions as they align with the human context. These rubrics demonstrate how students’ skills can vary along each dimension, and also provide a template for scoring integrated assignments for other CS topics. Overall, this work demonstrates how to integrate human concerns with technical content in a way that deepens technical rigor and supports instructor pedagogical content knowledge.

This project aims to improve LGBTQ (lesbian, gay, bisexual, trans, and queer) representation in the University of Utah's discrete mathematics course. Many practice problems in the course textbook rely on heteronormative and/or cisnormative premises. We developed alternatives that maintained the original mathematical content while including minority identities, and then deployed them in a homework assignment. Students also completed a survey on their opinions of the new questions. Most students were open to the inclusion of LGBTQ representation in their homework, and many applauded it. However, students also suggested that subtle wording was preferable, and that affirming problems should be sprinkled across the course rather than concentrated in one assignment. Our experience provides an example of framing mathematical content to support an inclusive classroom climate, and we expect that our lessons learned can inform assignments that affirm minority identities throughout the CS curriculum.

Since intermediate CS students can use a variety of control struc- tures, why do their choices often not match experts' Students may not realize what choices expert prefer, find non-expert choices easier to read, or simply forget to write with expert structure. To disentangle these explanations, we surveyed 328 2nd and 3rd se- mester undergraduates, with tasks including writing short func- tions, selecting which structure was most readable or best styled, and comprehension questions. Questions focused on seven control structure topics that were important to instructors (e.g., factoring out repeated code between an if-block and its else). Students frequently wrote with non-expert structure, and, for five topics, at least 1/3 of students (48% - 71%) thought a non-expert struc- ture was more readable than the expert one. However, students often made one choice when writing code, but preferred a different choice when reading it. Additionally, for more complex topics, stu- dents often failed to notice (or understand) differences in execution caused by changes in structure. Together, these results suggest that instruction and practice for choosing control structures should be context-specific, and that assessment focused only on code writing may miss underlying misunderstandings.

Experts often use particular control flow structures to make their code easier to read and modify, such as using the logical operator AND to conjoin conditions rather than nesting separate if statements. Within Boolean expressions, experts take advantage of short-circuit evaluation by ordering their conditions to avoid errors (such as checking that an index is within the bounds of an array before examining the value at that index). How well do students understand these structures? We investigate students' use and understanding of conjoined versus separate conditions within a larger assessment of 125 undergraduate students at the end of their second- and third-semester CS courses (in algorithms & data structures and introductory software engineering). The assessment asked students to: write code where an edge case error could be avoided with short-circuit evaluation, revise their code with nudges towards expert structure, and answer comprehension questions involving code tracing. When writing, students frequently forgot to check for a key edge case. When that case was included, the check was often separated in its own if-statement rather than conjoined with the other conditions. This could indicate a stylistic choice or a belief that the check had to be separated for functionality. Notably, students who included all necessary conditions rarely exhibited the error of ordering them incorrectly. However, with code comprehension, students demonstrated significant misunderstandings about the effects of condition ordering. Students were more accurate on comprehension tasks with nested ifs than conjoined conditions, and this effect was most pronounced when the ordering of the conditions would lead to errors. When conditions were conjoined in a single expression, only 35% of students recognized that checking a value at an index before checking that the index was in bounds would lead to an error. However, 54% of students recognized the problem when the conditions were separated into individual if-statements. This demonstrates a subtlety in code execution that intermediate students may not have mastered and emphasizes the challenges in assessing students' understanding solely via the way they write code.

When middle school students encounter computer models of science phenomenon in science class, how do they think those computer models work? Computer models operationalize real-world behaviors of selected variables, and can simulate interactions between the modeled elements through programmed instructions. This study explores how middle school students think about the high-level semantic meaning of those instructions, which we term rules . To investigate this aspect of students’ computational thinking, we developed the Computational Modeling Inventory and administered it to 253 7 th grade students. The Inventory included three computer models that students interacted with during the assessment. In our sample, 99% of students identified at least one key rule underlying a model, but only 14% identified all key rules; 65% believed that model rules can contradict; and 98% could not distinguish between emergent patterns and behaviors that directly resulted from model rules. Despite these misconceptions, compared to the “typical” questions about the science content alone, questions about model rules elicited deeper science thinking, with 2--10 times more responses including reasoning about scientific mechanisms. These results suggest that incorporating computational thinking instruction into middle school science courses might yield deeper learning and more precise assessments around scientific models.

Good style makes code easier for others to read and modify. Control flow is one element of style where experts expect particular structure, such as conjoining conditions rather than nesting if statements. Empirical work is necessary to understand why novices use poor style, so they can be taught to use good style. Previous work shows that many students know what control flows experts prefer, but may say that novice-styled code is more readable. Yet, these same students showed similarly high comprehension across both expert-and novice-styled code. We propose a replication of that work that more fully assesses students' code comprehension and code writing. Our replication focuses on students who are earlier in their computer science courses and are less likely to be majors, to determine whether the pattern of results is particular to students who are relatively attuned to style concerns. Our pilot of the proposed replication finds that: students in this new population are less able to identify expert code; expert style may reduce comprehension for some control flows; and writing with good style does not always predict a preference for reading code with good style.

Teaching students to write code with good style is important but difficult: in-depth feedback currently requires a human. AutoStyle, a style tutor that scales, offers adaptive, real-time holistic style feedback and hints as students improve their code. An in-situ study with 103 undergraduate students in a CS class compared AutoStyle to a control tutor which only offered ABC score. While students improved the style of their code in both cases, students working with AutoStyle were more likely to use an appropriate language idiom and to improve their recognition of good style. However, students struggled to implement style improvements, even when hints recommended specific functions.

Can experimenting with three-dimensional (3D) physical objects in mixed-reality environments produce better learning and enjoyment than flat-screen two-dimensional (2D) interaction? We explored this question with EarthShake: a mixed-reality game bridging physical and virtual worlds via depth-camera sensing, designed to help children learn basic physics principles. In this paper, we report on a controlled experiment with 67 children, 4--8 years old, that examines the effect of observing physical phenomena and collaboration (pairs vs. solo). A follow-up experiment with 92 children tests whether adding simple physical control, such as shaking a tablet, improves learning and enjoyment. Our results indicate that observing physical phenomena in the context of a mixed-reality game leads to significantly more learning and enjoyment compared to screen-only versions. However, there were no significant effects of adding simple physical control or having students play in pairs vs. alone. These results and our gesture analysis provide evidence that children's science learning can be enhanced through experiencing physical phenomena in a mixed-reality environment.