Claudio Mirolo

Characterising code quality is a challenge that was addressed by a previous ITiCSE Working Group (Börstler et al., 2017). As emerged from that study, educators, developers, and students have different perceptions of the aspects involved. The perception of code quality by CS1 students develops from the feedback they receive when submitting practical work. As a consequence of increasingly large classes and the widespread use of autograders, student code is predominantly assessed based on functional correctness, emphasising a machine-oriented perspective with scarce or no feedback given about human-oriented aspects of code quality. Such limited perception of code quality may negatively impact how students understand, create, and interact with code artefacts. Although Börstler et al. concluded that "code quality should be discussed more thoroughly in educational programs", the lack of materials and time constraints have slowed down progress in that regard. The goal of this Working Group is to support CS1 instructors who want to introduce a broader perspective on code quality in their classroom, by providing a curated list of examples and activities suitable for novices. In order to achieve this goal, we have extracted from the CS education literature a range of examples and activities, which have then been analysed and organised in terms of code quality dimensions. We have also mapped the topics covered in those materials to existing taxonomies relevant to code quality in CS1. Based on this work, we provide: (1) a catalogue of examples that illustrates the range of quality defects that could be addressed at CS1 level; and (2) a sample set of activities devised to introduce code quality to CS1 students. These materials have the potential to help educators address the subject in more depth.

Characterising code quality is a challenge that was addressed by Börstler et al. 's working group in 2017. As emerged from their study, educators, developers and students have different perceptions of the manifold aspects involved, and a major conclusion of that WG was that "code quality should be discussed more thoroughly in educational programs" [2, p. 70]. However, the lack of materials and the time constraints have slowed down progress in that regard. The goal of this working group is to propose manageable ways to address code quality in the CS1 classroom, with a particular focus on activities that help students become aware of and improve the quality of their code. To achieve this goal, we will (a) extract from the literature a comprehensive set of quality issues which will then be classified according to the appropriate strategies to fix them; and (b) circulate a survey to explore the instructors' views on code quality issues and the way they deal with (or ignore) them. Based on this work we aim to produce: (1) a taxonomy of code quality issues with associated examples, as well as (2) a sample set of teaching materials to introduce those issues to CS1 students.

Whilst most undergraduate students eventually produce functionally correct code, they often disregard their code style and overall quality when it is not graded. As reported by the literature, quality defects affect both code structure and code style, and these issues seem to persist even in later years. This paper reports on the potential of a low-cost intervention that directed CS2 students to revise and refactor their code, with a specific focus on code structure, by resorting to a range of online refactoring resources. A "refactor-your-working-solution'' assignment received 73 submissions by 47 students. For each cleaned solution, students were required to provide a one-page report documenting their improvements step-by-step, and include a short reflection on their learning. Their efforts to clean code and their reflections are analysed in this experience report. Most students were able to apply multiple refactoring steps as well as other editing steps to improve their code style. In particular, we have identified a wide range of code smells in their code, hence gaining insights on their success in locating and removing 90% of them. Additionally, students' reflections appear to indicate an increased awareness as to the importance of readability and the need to develop more consistent habits when planning, coding and documenting their software.

Computing education (CE), the scientific foundation of the teaching and learning of subject matter specific to computing, has matured into a field with its own research journals and conferences as well as graduate programmes. Yet, and unlike other mature subfields of computer science (CS), it is rarely taught as part of undergraduate CS programmes. In this report, we present a gap analysis resulting from semi-structured interviews with various types of stakeholders and derive a set of arguments for teaching CE courses in undergraduate CS programmes. This analysis and the arguments highlight a number of opportunities for the discipline of CS at large, in academia, in industry, and in school education, that would be opened up with undergraduate CE courses, as well as potential barriers to implementation that will need to be overcome. We also report on the results of a Delphi process performed to elicit topics for such a course with various audiences in mind. The Delphi process yielded 19 high-level categories that encompass the subject matter CE courses should incorporate, tailored to the specific needs of their intended student audiences. This outcome underscores the extensive range of content that can be integrated into a comprehensive CE programme. Based on these two stakeholder interactions as well as a systematic literature review aiming to explore the current practices in teaching CE to undergraduate students, we develop two prototypical outlines of such a course, keeping in mind that departments may have different preferences and affordances resulting in different kinds of CE offerings. Overall, input from external stakeholders underscores the clear significance of undergraduate CE courses. We anticipate leveraging this valuable feedback to actively promote these courses on a broader scale.

Students’ difficulties to learn concurrent programming are well known amongst Computer Science instructors. While in the International Computing Education community it is still up to debate the extent to which such topic should be included in pre-university curricula, based on our country’s Ministerial guidelines for technical high schools with a specialization in Computer Science, students are expected to acquire key concurrent programming skills. With the aim of getting insights about the nature of students’ difficulties, as well as to identify possible pedagogical approaches to be adopted by teachers, we have undertaken an investigation on students’ perception, proficiency and self-confidence when dealing with concurrency and synchronization tasks. We then present the results of a preliminary study carried out by submitting a survey in a couple of representative high schools of our area. The survey includes subjective perception questions as well as small program comprehension tasks addressing students’ understanding of thread synchronization. Moreover, we also analyze students’ self-confidence in connection with their actual performance in such tasks. A total of 68 high school students were engaged in the survey. Our findings indicate that students’ perception of self-confidence tends to weakly correlate to their actual performance, although more in general they express a low self-confidence level in relation to the topic. In particular, the results clearly show that the concept of thread synchronization is especially difficult to master for a large majority of them.

This working group concerns the adoption of computing education (CE) in undergraduate computer science (CS) programmes. Such adoption requires both arguments sufficient to persuade our departmental colleagues and our education committees, and also curricular outlines to assist our colleagues in delivery. The goal of the group is to develop examples of both arguments and curricular outlines, drawing on any prior experience available.

Programming plays a paramount role in many educational policies and initiatives. However, the current focus on coding skills poses the risk of giving students an overly simplistic and impoverished idea of what programming means and involves. Their experiences would be much more significant if learning encompassed understanding the richness of the nature of programs. Programs permeate our lives more inextricably than might often be recognised, and all citizens of the digital era could benefit from understanding their multifaceted nature. A fundamental component of such an understanding is getting a sense of how programs are created and work (i.e., the programming process). But programs are strange creatures that escape simple definitions. To the best of our knowledge, there is no Nature of Programs framework that teachers and policy makers can use to shape their practice and targets. In this working group we developed such a framework, by collecting and organising contributions from the literature and the computer science education community. The paper presents the framework and the rationale behind its development. It is anticipated that the framework can be used to inform the design of sound curricula, and support teachers and learners to understand the bigger picture around programming.

When we “think like a computer scientist,” we are able to systematically solve problems in different fields, create software applications that support various needs, and design artefacts that model complex systems. Abstraction is a soft skill embedded in all those endeavours, being a main cornerstone of computational thinking. Our overview of abstraction is intended to be not so much systematic as thought provoking, inviting the reader to (re)think abstraction from different – and perhaps unusual – perspectives. After presenting a range of its characterisations, we will explore abstraction from a cognitive point of view. Then we will discuss the role of abstraction in a range of computer science areas, including whether and how abstraction is taught. Although it is impossible to capture the essence of abstraction in one sentence, one section or a single paper, we hope our insights into abstraction may help computer science educators to better understand, model and even dare to teach abstraction skills.